What Article 46(2)(c) standard contractual clauses require when data leaves the EEA
When personal data flows from the EEA to an importer whose processing is not subject to the GDPR, the exporter needs an Article 46 safeguard unless an adequacy decision covers the destination. The 2021 standard contractual clauses adopted by Commission Implementing Decision (EU) 2021/914 are the safeguard most organizations use. They come in four modules (controller to controller, controller to processor, processor to processor and processor to controller), and the module you pick must match the real roles of each party. For controller-to-processor and processor-to-processor flows, the clauses also carry the Article 28(3) and (4) requirements, so the contract doubles as the processor agreement. Pick the wrong module and the safeguard may not cover the flow at all, so mapping roles before drafting is the first task.
The hard part is the assessment, not the signature. Under Clause 14, both parties warrant that they have no reason to believe the destination country's laws and practices, including public authority access, stop the importer from meeting its obligations. Making that warranty honestly means documenting the local legal position, the likelihood of access to the data in practice, and the supplementary measures that close the gap. Under Clause 15, the importer must review requests from public authorities, challenge unlawful ones where there are reasonable grounds, and notify the exporter. Annex II then requires a written description of the technical and organisational measures, which the decision illustrates with 17 examples such as pseudonymisation, encryption, protection in transmission and storage, and limited retention. The exporter should confirm with counsel which of these measures its own systems actually apply.
The clauses are a contract, not a certificate. No authority or auditor issues approval for using them, and signing them does not transfer responsibility for the outcome. The controller or exporter owns the transfer, its assessment and the evidence behind the Clause 14 warranty, and a provider that offers the clauses as a template still needs its own record of the assessment. Before signing, ask the importer for its Clause 15 request-handling procedure and its Annex II description, and check that the annex matches the systems that will hold the data. Keep the assessment, the annex and the correspondence under version control so they can be shown to a supervisory authority later.
Which transfers and parties the clauses cover
Before any clause is signed, the organization has to establish whether a data flow is a transfer at all and which relationship it creates. Each card below is a scoping decision that determines whether Decision (EU) 2021/914 applies, which module fits, and who has to sign and maintain it.
Confirm the flow is a transfer
A transfer exists when an exporter subject to the GDPR makes personal data available to an importer in a third country. Remote access from outside the EEA to data stored inside it counts as a transfer, and so does a support engineer viewing records from abroad. Map each such flow with the engineering and vendor management teams before selecting clauses, because a flow that is missed in scoping is missed in the contract too.
Pick the module for each role
The four modules cover controller to controller, controller to processor, processor to processor and processor to controller relationships. The exporter and importer must agree their roles in writing, and a mismatched module means the contract does not describe the actual processing. Legal and privacy teams usually own this decision, with platform engineering confirming who actually processes the data.
Trace onward transfers and sub-processors
An importer that passes data to its own sub-processors in another country creates a further transfer, and the clauses have to reach down that chain. Ask each importer for its sub-processor list, the locations of those providers and the flow-down terms used. Procurement and the data protection team should refresh this list whenever a provider changes.
Check importers already under Article 3(2)
An importer outside the EU that is itself subject to the GDPR under Article 3(2) for the same processing is not a case where the clauses are the usual tool, because the transfer rules protect data that leaves the GDPR's reach. Confirm this with counsel, since the importer's GDPR obligations do not remove the exporter's duties and the analysis depends on the exact processing. Document the reasoning in the record of processing.
Assign owners for each flow
Each mapped transfer needs a named business owner, a module, a signed contract and a current list of the parties involved. Engineering teams own the technical data flows, legal owns the contract, and the DPO or privacy lead reviews the scoping. Without an owner, the register of transfers falls out of date as systems and vendors change.
How an assessor tests the clauses and their supporting evidence
This table sets out what an assessor checks for each part of the 2021 standard contractual clauses, the evidence that usually satisfies it, and the findings that appear most often. Read each row as a question the assessor will ask and the document or configuration that should answer it. Where a finding is listed, it is usually a documentation gap that is quicker to fix before the review than during it.
| Area | What the assessor tests | Evidence that passes | Common finding |
|---|---|---|---|
| Executed clause sets per module | That each transfer relationship uses the correct module (controller to controller, controller to processor, processor to processor or processor to controller) and that the clauses are signed by both parties. | Signed clause sets per transfer, a register mapping each importer to its module, and the Article 28 terms for processor modules. | Missing module selection, or a generic clause set signed without the module choice completed. |
| Predecessor clauses | Whether any contract still relies on the repealed 2001 or 2010 clauses past the end of the transition period. | A contract inventory showing the clause version in use and the date each agreement was moved to the 2021 clauses. | Contracts still citing the 2010 clauses or the 2001 clauses, carried forward during renewals without review. |
| Clause 14 transfer assessment | That the exporter and importer documented a reasoned assessment of the destination country's laws and practices, including public authority access, before relying on the clauses. | A dated assessment per destination, the sources reviewed, the conclusion reached and the supplementary measures chosen, with a named reviewer. | Assessments that repeat a generic country statement, have no date, or do not address public authority access. |
| Clause 15 request handling | That a written procedure exists for receiving, reviewing and, where grounds exist, challenging public authority requests, and that the importer notifies the exporter as the clauses require. | A request-handling procedure, a log of requests received and how each was reviewed, and records of challenges or notifications made. | A procedure that does not name who reviews requests, or no log even though the importer has received requests. |
| Annex II measure descriptions | That the technical and organisational measures are described for this transfer, not as general policy text, and that they cover the examples the annex lists such as encryption, access control and logging. | A measure description tied to the specific processing, system names, the encryption approach and the retention rules applied to the transferred data. | Measures described generically, such as stating that the organization applies appropriate security, with no link to the transfer. |
| Link from measures to system configuration | That the stated measures exist in the running environment, with configuration records that an assessor can sample. | Configuration exports, key management records, access reviews, log settings and backup policies that match the Annex II text. | Annex II promises encryption or logging that the configuration records do not show, or records that were not kept current. |
| Change control over the evidence | Whether the clauses, assessments and measure descriptions are reviewed when the transfer, the importer or the destination law changes. | Version history for each document showing what changed, when and by whom, with dated review entries. | Assessments that were never reviewed after a change in the importer's services or sub-processors. |
How to put the clauses into effect, step by step
This sequence turns the 2021 standard contractual clauses from a signed document into a transfer your organization can explain, defend and maintain. Each step produces a record that the next step relies on.
Map every transfer and its roles
List each flow where personal data leaves the EEA or reaches a party outside the GDPR's reach, and record the sender, the recipient and the role each party plays. Confirm with engineering which systems, support teams and sub-processors actually touch the data, because transfers often exist in remote access and vendor tooling that no one has written down. The output is a transfer register with one row per flow. The step is complete when the register lists every importer and the module that each flow will need.
Select the modules and complete the annexes
Match each flow to one of the four modules: controller to controller, controller to processor, processor to processor or processor to controller. For controller-to-processor and processor-to-processor flows, check that the clauses cover the Article 28(3) and (4) terms, and confirm the processing instructions, subject matter, duration and sub-processor arrangements in the annexes. The output is a signed set of clauses per flow with completed annexes. Legal counsel usually owns the drafting, and the importer confirms the factual content.
Run the Clause 14 assessment of local law
For each importer, assess whether the destination country's laws and practices, including disclosure duties and public authority access, could stop the importer from meeting the clauses. Use the specific transfer, the categories of data and the importer's actual disclosure history as inputs, and record the sources you relied on. Where the assessment finds a risk, document the supplementary measures that address it. The output is a written assessment signed by the exporter, reviewed by the importer and dated. Ask counsel or the data protection officer to confirm the conclusion before the transfer starts.
Document Clause 15 handling of authority requests
Set out how the importer receives, logs and reviews any request from a public authority for transferred data. The procedure should state who decides, how the importer tests whether a request is lawful, when it challenges an unlawful request, what it tells the exporter and how much data it discloses. Ask the importer to show a worked example of its procedure, and check that its staff know who to escalate to. The output is an approved procedure and a contact list. The step is complete when both parties have accepted the same written process.
Define Annex II measures in the system design
Translate the Annex II description of technical and organisational measures into configured controls, such as encryption in transit and at rest, user identification and authorisation, event logging, pseudonymisation where it fits and limited retention. Engineering and security teams own the configuration, and each measure should name the system, the owner and the test that proves it works. Where a measure depends on who holds encryption keys, state that explicitly, because the Clause 14 assessment may rely on it. The output is an Annex II table linked to configuration evidence.
Record the outputs and set review triggers
Assemble the transfer register, signed clauses, Clause 14 assessment, Clause 15 procedure and Annex II evidence into one controlled record, with a version and an owner for each item. Set triggers that reopen the assessment, such as a change in the importer's sub-processors, a new disclosure request or a change in the destination country's law. Version control and role-based permissions in a self-hosted documentation platform can hold this record and show who changed what. The output is a single reviewable file set that an independent auditor or supervisory authority can follow from transfer to safeguard.
Which Annex II technical measures to describe, by system layer
Annex II asks the parties to describe how personal data is pseudonymised and encrypted. The description turns on where keys sit and who can use them, because a measure that encrypts data while the importer holds the keys describes a different protection than one where the exporter controls key material. Write the description from the system outward, starting with the stores and transfer paths that carry the data.
- Scope of encryption: Name each database, object store, file share, backup and replica that holds transferred personal data, and state whether it is encrypted at rest.
- Key custody: State who generates, stores, rotates and revokes keys, and whether any key material is held outside the importer's control.
- Pseudonymisation point: Describe where identifiers are replaced, and where the mapping table lives and which roles can reach it.
- Evidence: Keep key management configuration exports, rotation logs and screenshots or exports of encryption settings for each storage service in scope.
Confirm the current wording of the pseudonymisation and encryption examples in Decision (EU) 2021/914 before copying any phrasing into Annex II.
The identification and authorization examples in Annex II describe how users and services prove who they are and what they may do. Engineers usually hold this material in the identity provider, the directory and the application's role model, so the description should point to those systems and state how they connect to the data flows covered by the clauses.
- Identity sources: Name the directory or identity provider that issues accounts for staff, customers and service accounts, and state whether accounts are personal or shared.
- Authentication: Describe the factors used for interactive and administrative access, and how privileged access differs from standard access.
- Role model: List the roles that can read, export, modify or delete transferred data, and who approves role assignments.
- Service identities: Inventory machine accounts and API keys that move data across the transfer, with an owner and a rotation method for each.
- Evidence: Retain role definitions, periodic access review records, and a current account inventory that matches the systems in the transfer description.
Ask the importer to confirm that its access review cycle covers the same systems named in the description, because assessors often find gaps between the documented model and the live directory.
The Annex II examples on protection in transmission and storage describe the environment that carries and holds the data, separate from the cryptographic choices covered in the encryption tab. This group is about the network paths, hosts and platform controls that surround each system. Map every hop in the transfer, including remote support sessions and administrative tunnels, because each hop needs a stated protection.
- Transfer paths: List each connection between exporter, importer and any sub-processor, and state how traffic is protected in transit.
- Network segmentation: Describe how systems holding transferred data are separated from general networks, and which ingress and egress rules apply.
- Host hardening: State the baseline used for operating systems, containers and databases, and who reviews drift against it.
- Storage platform controls: Describe access paths to storage, snapshot and replication settings, and how storage administrators are logged and limited.
- Evidence: Keep network diagrams, firewall or security group exports, configuration baselines and scan results for hosts in the transfer scope.
Check that the network diagram matches the production topology at the date of signature, since diagrams drawn for the contract often lag behind infrastructure changes.
The event logging example in Annex II asks the parties to describe what is recorded about processing of personal data. Logs are the measure that lets a party show, after the fact, who accessed or changed transferred data. The description should name the events captured, where they are stored, who can read them, and how long they are kept, with the importer's side of the transfer included.
- Events captured: List the access, export, configuration change, privileged action and failed authentication events that are recorded for systems in scope.
- Log integrity: State how logs are protected from alteration, such as write-once storage or forwarding to a separate account, and who holds administrative rights over the log store.
- Time and identity: Describe how clocks are synchronized and how each event links to a named user or service identity.
- Review: Name the team that reviews alerts or log samples, and how often and through which tool.
- Evidence: Retain log source inventories, sample event records for each event class, and records of log review or alert handling.
Confirm that log retention is set deliberately, because the limited retention measure applies to logs as well as to the personal data they describe.
The limited retention example in Annex II asks the parties to describe how long transferred data is kept and how it is removed. A retention statement is only as strong as the deletion process behind it, so the description should tie each dataset to a period and a technical mechanism that enforces it, including copies that people often forget, such as backups, replicas, exports and logs.
- Retention schedule: Set a period for each dataset transferred, tied to the purpose recorded in the transfer description.
- Deletion mechanism: Describe the scheduled jobs, lifecycle policies or manual procedures that remove data at the end of each period.
- Copies and backups: State how long backups and replicas keep deleted data, and how restores avoid bringing back data that should have been removed.
- Sub-processors: Require the same retention limits from any sub-processor that stores transferred data, and record how they confirm deletion.
- Evidence: Keep retention schedules, deletion job logs, lifecycle policy exports, and sample deletion confirmations for each dataset.
Confirm the wording of the retention example in the decision text, and check that the periods stated here match the retention settings in each system.
Evidence that shows the clauses are in force and working
An assessor or supervisory authority does not accept a signed template as proof that a transfer is protected. The records below show that the clauses were executed, that the transfer is documented, that the importer's country was assessed, and that the measures in place are the ones described. Each record needs an owner and a review date, because stale files are the most common gap.
Signed clause sets with completed annexes
Keep the executed version of the clauses for each importer, with the correct module selected for the flow (controller to controller, controller to processor, processor to processor or processor to controller). Annex I must name the parties, describe the transfer and state the categories of data and data subjects. Confirm that the signed set is the version in force, since clauses based on the repealed 2001 and 2010 decisions only remained a valid basis until 27 December 2022. A signed copy with a blank Annex I is not evidence of anything.
Transfer register entries
Maintain one register entry per transfer flow that links the importer, the module, the purpose, the storage location, the sub-processors and the safeguard relied on. Each entry should point to the signed clause set and to the Clause 14 file. Reconcile the register against actual data flows, including support access from outside the EEA and backups hosted by a third party, because an unlisted flow is a flow the organization cannot defend.
Clause 14 assessment files
Clause 14 requires the parties to warrant that they have no reason to believe the destination's laws and practices stop the importer from complying. The file should record the laws reviewed, the public authority access rules considered, the sources used, the conclusion and the reviewer's name and date. Record the supplementary measures chosen and why they address the risk identified. Refresh the file when the destination's law or the importer's circumstances change, and do not treat a file written once as permanent.
Clause 15 request logs and legal review notes
Clause 15 obliges the importer to review each public authority request and to challenge it where there are reasonable grounds. Keep a log of every request received, the date, the requesting authority, the legal basis cited, the data affected, the review outcome, any challenge filed and the exporter notice given. Attach the legal review note to each entry. An empty log is only credible if the importer can show how it would have logged a request, so confirm the intake route with the importer in writing.
Annex II measure records
Annex II requires a description of the technical and organizational measures, and it lists 17 examples such as pseudonymisation, encryption, user identification and authorization, protection in transmission and storage, events logging and limited retention. Each measure in the annex should have a configuration record, an owner and a test result that shows it operates. A description of encryption without the key management record, or logging without a sample of retained events, will not satisfy an assessor.
Version history of the evidence
An assessor will ask what changed, when and who approved it. Store clause sets, Clause 14 files, register entries and Annex II records in a wiki or document system that keeps every revision, records authorship and allows comparison between versions. XWiki keeps version control on page changes with what changed, when and by whom, and BookStack assigns abilities through roles that can be restricted per shelf, book, chapter or page. Confirm that the chosen system exports its history, because the record must survive a platform change.
What meeting Article 46(2)(c) costs in money and effort
This table lists each cost component of putting the 2021 standard contractual clauses in place, who is paid for it, whether it is one-time or recurring, and what pushes it up. Use it to structure a request for quote, since no figures for these components were supplied and each one depends on your transfer map.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Transfer mapping | Internal privacy and engineering staff, sometimes an implementation partner | One-time, then recurring when flows change | Number of systems, sub-processors and destination countries |
| Legal drafting and negotiation of clauses | Outside counsel or internal legal, plus the importer's counsel | One-time per contract, with reopening on change | Number of importers, choice of modules, and how many annex edits are negotiated |
| Clause 14 assessment of local laws | Legal counsel with knowledge of the destination country, or a specialist provider | Initial assessment, then recurring review when laws or practices change | Legal complexity of the destination country and the sensitivity of the data |
| Clause 15 handling procedure | Internal legal and security staff who run the request review process | One-time procedure design, recurring operation | Volume of public authority requests and the number of challenges pursued |
| Technical measure engineering for Annex II | Internal engineers or an implementation partner building encryption, access control, logging and retention | One-time build, recurring operation and key management | Number of systems in scope, self-hosting versus vendor hosting, and key ownership model |
| Evidence upkeep | Internal compliance staff maintaining the transfer register and Annex II records | Recurring | Frequency of processing changes and how evidence is stored and versioned |
| External review | Independent legal or privacy reviewers, and where relevant an independent auditor for an assurance scope | Usually one-time per major change, sometimes recurring | Scope of review and whether the reviewer is asked to test controls, not just read documents |
| Software licenses for tooling | Vendors of commercial compliance or document management tools | Recurring subscription or licence fees | Seat counts and modules. Self-hosted open-source tools can remove some of this spend, but support and hosting remain |
Who owns the clauses, who prepares the systems and who assesses them
The exporter and importer own the transfer. They decide which module applies, sign the clauses, identify each transfer and make the Clause 14 judgment about whether the destination country's laws and practices stop the importer from meeting its obligations. The Clause 15 response to a public authority request also sits with the importer, which must review the request and challenge it where there are reasonable grounds. An implementation partner can gather facts and draft analysis, but the conclusions and the accountability for them stay with the organization's legal and privacy leadership.
- Module selection: Confirm whether each flow is controller to controller, controller to processor, processor to processor or processor to controller, and record the reason.
- Clause 14 conclusion: The exporter documents its assessment of the destination country's laws and practices and the basis for its conclusion.
- Clause 15 handling: Name who receives public authority requests, who reviews them and who decides on challenges.
- Annex II sign-off: The organization approves the description of technical and organizational measures that appears in the contract.
- Records: Keep the signed clauses, assessments and decisions in a form that can be produced to a supervisory authority.
Check that someone inside the organization can explain each Clause 14 conclusion without relying on the consultant who helped prepare it.
An implementation partner usually prepares the technical side of a transfer. This includes configuring the self-hosted platforms that process transferred data, enforcing access controls and encryption, setting logging and retention, and collecting the evidence that shows the Annex II measures are in place. DeployOpen plans, implements and documents this kind of work inside the client's own infrastructure. The partner does not make the legal decisions above, and it does not issue audit reports or certifications.
- System configuration: Set up encryption in transit and at rest, user identification and authorization, and event logging on the systems the clauses cover.
- Evidence packs: Produce configuration exports, access reviews, logging samples and retention settings that map to the measures the organization described.
- Hardening and documentation: Document how each platform is operated, backed up and restricted, so the Annex II description matches reality.
- Gap reports: Identify where a measure described in the contract is not yet implemented, and state what remains open.
- Change tracking: Keep configuration changes recorded so the evidence stays current after upgrades.
Check that the statement of work names each Annex II measure it covers and the evidence it will deliver, and that the partner's deliverables go to the organization, not to a third party claiming to attest to them.
Independent assessment is the role that tests the work. The GDPR requires no audit, attestation or certificate for transfers under Article 46, so an organization decides whether an external review is needed for its own assurance, for a customer or for a regulator. Where an assessor is engaged, it should be independent of the party that built the controls. A supervisory authority can examine transfers during an investigation, and that examination is not an audit the organization can order.
- Who qualifies: Depending on the context, an external auditor, an assessor under a certification scheme or the supervisory authority itself.
- Scope agreement: Agree in writing which transfers, modules and Annex II measures are in scope before testing starts.
- Independence line: The partner that configured the systems should not be the party that signs an assurance opinion on them.
- Certification limits: Any certification under Article 42 is voluntary, lasts for at most three years and does not reduce the responsibility of the controller or processor.
- Written findings: Ask for a report that states what was tested, the evidence reviewed and the exceptions found.
Check whether the assessor's credentials and any certification claims can be verified with the issuing body before you rely on them.
Organizations often outsource the parts of a transfer programme that require specialist hands but not the decisions. Common examples are technical configuration of self-hosted platforms, evidence collection, drafting of transfer impact documentation for review, and independent testing. Costs follow the amount of systems in scope, the number of transfers and how much of the evidence already exists. Fees and effort depend on the written scope, so organizations should ask for a quote that separates each role.
- Typically outsourced: Platform hardening, encryption and access configuration, logging setup and evidence packs.
- Usually kept in-house: The choice of module, the Clause 14 conclusion, the Clause 15 decision and the signed contract.
- Recurring work: Re-checking evidence after upgrades, reviewing new public authority requests and updating the Annex II description when systems change.
- One-time work: Initial mapping of transfers, first configuration and first evidence collection.
- Quote request: Ask the provider to list deliverables by role, state what is excluded and say how ongoing support is priced.
Check that the division of work in the quote matches the division in your contract and governance records.
Where organizations fall short on standard contractual clauses
Most gaps in SCC programs are paperwork that was never maintained, not missing clauses. The cards below cover the failures assessors and regulators meet most often, and each ends with the check that closes it. Work through them against your live transfer inventory, not only the signed contract file.
Predecessor clauses still in use
Some contracts still rely on the clauses adopted under Decisions 2001/497/EC and 2010/87/EU. Those decisions were repealed from 27 September 2021, and contracts based on them were deemed to provide appropriate safeguards only until 27 December 2022. Any agreement signed or amended on the old text, or left unchanged after that deadline, does not support the transfer it describes. Action: list every transfer contract by clause version and replace any old-version agreement with the 2021 clauses.
Generic Annex II measures
Annex II requires a description of the technical and organisational measures that actually protect the transferred data. A common failure is boilerplate that lists encryption and access control in general terms without naming the keys, systems, roles or retention periods used for this flow. Assessors compare the annex with the architecture, and a generic text fails that comparison. Action: rewrite Annex II for each flow with the specific controls, owners and retention rules, and confirm them against current configuration.
No documented Clause 14 assessment
Under Clause 14 the parties warrant that they have no reason to believe the destination country's laws and practices prevent the importer from complying. Many organizations sign this warranty without a written analysis of the destination's surveillance and disclosure laws, the importer's own government access history, or the practical likelihood of an order. Without that record, the warranty is an unsupported statement. Action: write a dated assessment for each destination, covering the law, the importer's prior requests and the measures relied on, and refresh it when either changes.
No Clause 15 procedure for authority requests
Clause 15 obliges the importer to review each public authority request and to challenge unlawful ones where there are reasonable grounds. Teams often have no intake route, so a request from a foreign agency reaches an engineer or a support desk and is handled informally. Without a defined path, the importer cannot show that it reviewed, challenged or minimized disclosure as the clause requires. Action: define who receives requests, the legal review steps, the challenge criteria, the minimum disclosure rule and the log kept for each request.
Clause sets not tracked against sub-processors
Where the importer engages sub-processors, the clauses and the flow-down obligations must follow each new or replaced sub-processor. Organizations often update the vendor list without updating the clause set, leaving data flowing to parties that are not covered by any current agreement. The gap is usually invisible until an audit asks for the chain of contracts behind a specific data set. Action: tie every sub-processor change to a ticket that confirms the clause module, the Annex I and II entries, and the destination assessment before data moves.
Questions buyers ask about standard contractual clauses
What does it cost to put standard contractual clauses in place?
The cost has two parts: legal and assessment work, and the technical work to make the measures in Annex II true. Legal review of the module choice, the annexes and the Clause 14 assessment is usually paid to your lawyers or outside counsel. Engineering work, such as encryption, access control, logging and retention settings, is paid to whoever builds and runs the systems. Most of the spend is one-time, but the clauses need upkeep: reviewing them when laws change, updating the transfer assessment when a provider or location changes, and maintaining the Annex II description. Costs rise with the number of transfers, the number of importers, the number of countries where data is accessed and the complexity of the data flows. Ask any partner for a fixed-scope quote that lists each transfer, each module, each annex deliverable and what is excluded. DeployOpen does not publish prices. A quote follows from the written scope.
How long does a standard contractual clauses project take?
The duration depends on how many transfers you have, how well mapped they are and how quickly your team can answer questions about where data goes and who can access it. A project that starts from an incomplete inventory of processors and sub-processors spends most of its time discovering facts. The team needs a data owner who can describe each flow, an engineer who can confirm technical settings, a legal reviewer who signs off on the module choice and the Clause 14 assessment, and someone who maintains the contract register afterward. Ask for a written timeline with dependencies, especially for transfers that depend on the importer's cooperation. No fixed duration applies to every organization, so confirm the estimate against your own inventory before you commit.
Can we prepare standard contractual clauses ourselves?
Yes, in many organizations the internal team can do the work, provided it has the legal and technical skills and the time. The clauses are a Commission decision, so they are not negotiated text in the usual sense, but the choice of modules, the docking and optional clauses, the governing law, the annexes and the transfer assessment still need legal judgment. Teams often underestimate the Annex II work, which requires a concrete description of each measure in place for each transfer. Decide early who owns each step, keep a single register of transfers and contracts, and check whether your lawyers are comfortable signing the Clause 14 assessment. If any part is missing internally, an implementation partner can fill the gap, but it does not replace the lawyer.
What can an implementation partner prepare, and what must the lawyer and auditor decide?
Your organization owns its transfers and its compliance decisions. An implementation partner can prepare the technical side: a map of systems and data flows, the configuration evidence behind each Annex II measure, access and logging records, encryption and key management designs, retention settings, and a documented process for handling public authority requests. A lawyer decides whether the clauses are the right tool, which module applies, what the Clause 14 assessment concludes and how to respond to a challenge under Clause 15. An independent auditor or assessor reviews controls where an assessment is required. A partner does not issue reports or certificates. Put this split in the statement of work so each deliverable has a named owner.
Are the standard contractual clauses enough after Schrems II-style reviews?
Signing the clauses is necessary but not sufficient. Clause 14 requires the parties to warrant that they have no reason to believe the destination country's laws and practices, including public authority access, prevent the importer from complying. That warranty must rest on an actual assessment of the destination's laws and how they are applied to your data. Where the assessment shows a gap, you need supplementary measures, such as encryption with keys the exporter controls, strict access limits and documented challenge procedures. Clause 15 obliges the importer to review and, where there are reasonable grounds, challenge unlawful public authority requests. Courts and supervisory authorities examine the evidence behind these warranties, so keep it current and be ready to show it.
How do the Annex II technical measures show up in our systems?
Annex II asks for a description of the technical and organizational measures that protect the transferred data, and it lists examples such as pseudonymisation and encryption, user identification and authorization, protection in transmission and storage, events logging and limited data retention. Engineers should turn each stated measure into a setting they can point to: TLS configuration, key storage location, role-based access rules, audit log retention and deletion jobs. For self-hosted platforms, the evidence is the configuration itself plus change history. Confirm with each vendor which features they actually support before you describe them in the annex, rather than assuming a default is correct for your deployment.
How should we keep the transfer documentation current?
Treat the clauses, annexes and transfer assessment as living records that change when systems, vendors or laws change. Store them in a versioned knowledge base so you can see what changed, when and by whom, and compare or roll back to earlier versions. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions. BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level, which helps limit who can edit the transfer register. Set a review trigger for each transfer, such as a new sub-processor or a change in hosting location, and assign an owner for the review.
How DeployOpen prepares systems and evidence for these clauses
DeployOpen prepares the technical side of standard contractual clauses under Decision (EU) 2021/914, and only that side. Work starts with a written scope that names each transfer in the data map, the module that applies to it (controller to controller, controller to processor, processor to processor or processor to controller), the self-hosted platforms in use, and the Annex II measures the client intends to describe. The scope also states who owns each decision. The client keeps responsibility for the Clause 14 assessment of the destination country's laws and practices, for the Clause 15 review of public authority requests, and for the wording of the signed clauses. DeployOpen does not give legal advice on the Clause 14 conclusion and does not decide whether a transfer may proceed.
Implementation happens inside the client's own cloud accounts, data centers or air-gapped networks, so the client controls where data and keys sit. DeployOpen deploys and hardens the self-hosted platforms, configures the measures the client's Annex II description relies on, such as encryption in transit and at rest, user identification and authorization, event logging and retention limits, and documents each setting. Where the client wants a technical measure that depends on keys held outside the importer's reach, the architecture and key custody model must be agreed in writing before build. Ask the partner to show how each measure is configured and tested in your environment, not only how it is described.
The evidence pack is the output that a client's own assessor or auditor will read. It typically includes configuration records, access and logging samples, backup and restore test results, change history and the Annex II mapping, all held under version control so that changes and their authors are traceable. Confirm which of these artifacts your team will own after handover, how they will be refreshed when a sub-processor or destination changes, and who signs off on each one. DeployOpen does not issue reports, attestations or certifications. The client's legal and privacy team, and any independent assessor they engage, decide whether the clauses are adequately supported.
