Decision (EU) 2023/1795 DPF: requirements and evidence

What the EU-US Data Privacy Framework decision requires of your transfers

Decision (EU) 2023/1795 is an adequacy decision that covers transfers from the EU to US organizations included in the Data Privacy Framework List maintained by the US Department of Commerce. For each transfer that relies on it, the controller or exporter must confirm that the specific recipient is on that list at the time of transfer and record that reliance in the transfer register. The decision is not an audit, attestation or certificate, and no EU body approves your organization. A US recipient that is missing from the list, or whose certification has lapsed, is not covered by the decision, so the transfer needs another Chapter V tool such as standard contractual clauses or it risks being treated as unauthorized.

This is harder in practice than it sounds. The transfer map is often incomplete, because teams know their primary vendor but not the sub-processors that vendor uses in the United States. Recipient status also changes: a company can be certified, lapse at renewal, or be removed, and a check made at contract signing says nothing about the next quarter. Ask each US importer for its current DPF List entry, the categories of data it covers, and its sub-processors, and record the date you checked. Then set a recurring check against the list, and define in advance what happens if a recipient drops off: suspend the flow, switch to standard contractual clauses, or move the data.

Plan for the legal position to move as well. The Commission's first periodic review (COM(2024) 451) set the next review after three years and said it would watch oversight developments in the United States, including Executive Order 14086, the Data Protection Review Court and Section 702 FISA. An appeal against the General Court's September 2025 judgment in Case T-553/23 is pending as Case C-703/25 P, and the Commission's adequacy page still lists US participants as adequate as of October 2026. Confirm the current status with the Commission and your data protection officer or counsel before relying on the decision, and keep a fallback mechanism documented for every US transfer.

Which transfers the decision covers and which it does not

The adequacy decision covers a data flow only when the US recipient is on the Data Privacy Framework List and the exporter is subject to the GDPR. Each card below is a separate scoping check, and each one has an owner in legal, procurement or engineering.

Recipient must be on the DPF List

Under Article 1 of Decision (EU) 2023/1795, the adequacy finding applies to organizations included in the Data Privacy Framework List maintained by the US Department of Commerce. Check the named legal entity, not the parent brand, because a subsidiary or affiliate may not be listed. Legal owns the confirmation that the importer's entity and its covered data types appear on the list on the date of transfer, and procurement should require that status in writing.

Non-listed US recipients need another tool

A transfer to a US recipient that is not on the DPF List is not covered by the decision, even when the recipient is a large US provider. Such transfers need another Chapter V tool, most often standard contractual clauses, supported by a transfer assessment. Procurement should flag vendors without DPF status early, and legal should decide whether a clause-based route is practical before the contract is signed.

Onward transfers from a listed importer

A listed importer that passes EU personal data to a third party, whether in the US or elsewhere, creates a separate transfer that the decision does not automatically cover. Engineering should map every outbound integration, backup target and support tool that receives the data. Legal should confirm that onward recipients are covered by a valid safeguard or by the importer's own contractual commitments.

Sub-processors in the processing chain

Each sub-processor that receives EU personal data on behalf of a processor forms part of the chain that must be understood. A listed importer may use cloud hosts, support vendors or analytics services that are not themselves on the list. Procurement should request the current sub-processor list with locations and certifications, and engineering should confirm, through configuration and access records, which parties can actually reach the data.

GDPR scope includes EEA senders

The decision matters only where the GDPR applies to the transfer. EEA-established entities that send personal data to a US recipient are in scope, including group companies that run systems from Europe for a US parent. Legal should confirm which entity is the exporter, and engineering should identify every EEA system, account or support team that pushes data across the Atlantic, including remote access from the US to EU-hosted data.

What the pending appeal and the 2024 review mean for a transfer you already run

As of October 2026, the EU-US Data Privacy Framework adequacy decision still applies, and the Commission's adequacy page continues to list US DPF participants as adequate. The General Court dismissed the action for annulment in Case T-553/23 Latombe v Commission on 3 September 2025, confirming that the United States ensured adequate protection when the decision was adopted. An appeal, Case C-703/25 P, was lodged on 31 October 2025 and published in the Official Journal on 22 December 2025. Nothing in that appeal suspends the decision, so a transfer to a certified importer remains covered while the appeal runs. The appeal does matter for risk planning, because a Court of Justice ruling could reach the decision itself. Confirm the current status on the Commission's adequacy page and in the case record on EUR-Lex before you sign off on any transfer design.

The first periodic review, COM(2024) 451 of 9 October 2024, concluded that US authorities had put in place the structures and procedures needed for the framework to function, reported more than 2,800 certified companies, and set the next review three years later. The review named four points the Commission will watch: the PCLOB reports on Executive Order 14086, the functioning of the Data Protection Review Court, possible amendments to Section 702 FISA, and appointments to the vacant PCLOB seats. An organization that relies on the DPF should assign an owner to track each point, record what changed, and reassess the transfer assessment when a change touches the access rules for its data.

Build a documented fallback before you need it. For each critical flow to a US importer, record the Article 46 tool that would take over if the decision were invalidated, usually the 2021 standard contractual clauses with a transfer impact assessment, and keep the signed clauses ready for the importer. Ask each importer to confirm in writing that it stays on the DPF List and to notify you of any lapse in certification. For flows that are not covered by a certification, such as a US recipient that has not certified, standard contractual clauses are the required tool, not an optional backup. Review the fallback at each Commission review and after any court ruling.

How an assessor or regulator tests reliance on the DPF

This table shows the questions a supervisory authority or assessor asks when a controller relies on the EU-US Data Privacy Framework adequacy decision, how each question is tested, the evidence to prepare, and the findings that usually cause problems. Read it as a checklist of the controller's own reasoning, since the DPF List is the primary public source and no DeployOpen or third-party certificate substitutes for that reasoning.

Question tested	Test approach	Evidence requested	Common findings
Is the importer on the DPF List at the time of transfer?	Check the importer's entry on the US Department of Commerce DPF List against the transfer date, not the date of the contract.	Dated screenshots or exports of the DPF List entry, with the name and identifier of the exact legal entity receiving the data.	Relying on a parent company's listing, or on a list entry that has lapsed or been removed.
Does the listing cover the data types and purposes transferred?	Compare the data categories and processing purposes in the importer's self-certification with the actual transfer described in the record of processing.	The importer's listed scope, the transfer inventory, and a written mapping of each data category to the covered scope.	HR or human resources data sent to an importer certified only for commercial data, or purposes outside the certified scope.
Did the exporter identify transfers that rely on the decision?	Sample the transfer inventory and check that each US recipient is tagged with the legal tool used, and that untagged recipients are reviewed.	Current transfer register, data flow diagrams, and records showing which tool applies to each recipient.	Shadow SaaS tools or support access from US affiliates that were never added to the register.
How are onward transfers and sub-processors handled?	Check that onward transfers from the importer are covered by contract terms and that sub-processors are identified and bound to equivalent protections.	Processor contracts, sub-processor lists with locations, and the importer's onward transfer commitments as described in its listing.	Sub-processors in third countries that no one assessed, or contracts that do not flow down DPF-equivalent obligations.
Does a fallback Chapter V tool exist if the decision is suspended or invalidated?	Ask whether the controller could continue lawful transfers under another tool, such as standard contractual clauses with a transfer assessment, without stopping the service.	A documented contingency plan, executed fallback contracts or readiness records, and a named owner who can trigger the switch.	No fallback prepared, reliance on the decision as the only basis, or fallback contracts that were drafted but never signed.
Does the controller monitor the decision's status?	Check that someone tracks the Commission's adequacy page, review reports, and the pending appeal, and records the outcome of each check.	Monitoring log with dates, decisions taken, and triggers for re-assessment of affected transfers.	Monitoring that stops after adoption, so the controller learns of a change only from a regulator or the press.

How to rely on the DPF in a controlled way, step by step

This sequence lets an exporter show, for each US flow, that the DPF covers the recipient, the data and the purpose, and that a tested fallback exists if the decision changes. Each step ends with a record you can hand to an auditor or supervisory authority.

Map every flow that leaves the EEA
The privacy or data governance lead, with system owners, lists each flow where personal data is sent or made accessible from the EEA to a US organization, including remote support and access from US locations. For each flow, name the importer, the exporter, the systems involved and the business owner. The step is complete when the register covers every US-linked flow and each entry names a single importer. Confirm with engineering that no flow is missing from integrations, SaaS subscriptions and support tooling.
Check each US recipient against the DPF List
For each named importer, the privacy lead searches the Data Privacy Framework List maintained by the US Department of Commerce and records whether the organization is listed, the date of the check, the entry date and the framework covered (EU-US, UK extension or Swiss-US where relevant). Transfers to US recipients that are not on the List are not covered by the adequacy decision and must move to another Chapter V tool, such as standard contractual clauses. The output is a dated screenshot or export of each listing, stored with the transfer register.
Confirm listing covers the data and purposes
A listing alone does not settle the question. The privacy lead compares each importer's self-certification scope with the data categories and processing purposes in the flow, and flags any mismatch, such as sensitive categories or purposes the importer has not declared. The output is a short scope note per importer, signed off by legal, that states which flows the listing covers and which need a different tool. Ask the importer to confirm in writing that its certification remains current.
Document onward transfers and sub-processor locations
The processor or controller team collects the importer's list of onward transfers and sub-processors, including their countries of processing and any access from outside the US. It checks that onward transfers are contractually bound to the same level of protection, as the DPF requires for onward transfers, and that each sub-processor appears in the records of processing. The output is a sub-processor map per flow, linked to the transfer register, that shows where data is stored and who can reach it.
Set a monitoring routine for list and legal changes
The privacy lead sets a recurring review that checks the DPF List for removals, lapses or scope changes, and follows the Commission's adequacy page, the outcome of the appeal in Case C-703/25 P, and any new Commission review. The first periodic review report also named the PCLOB reports on Executive Order 14086, the Data Protection Review Court, possible Section 702 FISA changes and PCLOB appointments as items the Commission would watch. Each review produces a dated log entry stating whether any flow needs a change in tool.
Prepare and test fallback clauses for critical flows
For flows the business cannot pause, the legal and engineering teams prepare standard contractual clauses and the transfer impact assessment that goes with them, and confirm with the importer that it will sign them on short notice. They also test whether the data can be re-routed or the flow stopped without a service outage. The output is a signed-ready clause set, a tested runbook for switching tools, and a record of the test date and results, so the organization can move a flow quickly if the adequacy decision is no longer relied upon.

Evidence that shows a DPF-based transfer is covered

A DPF-based transfer is covered only while the importer stays on the Data Privacy Framework List and the decision remains in force. The six artifacts below let the controller show, at any point, which recipient is covered, on what basis, and what it would do if that basis fell away. DeployOpen can prepare this pack, but it is evidence for the controller's own file, not an attestation.

Dated DPF List entry

Keep a dated screenshot or export of the importer's entry on the Data Privacy Framework List maintained by the US Department of Commerce, showing the covered data types and the verification date. Decision (EU) 2023/1795 covers only organizations on that List, so a transfer to a US recipient that is not listed falls outside the decision. Record who checked the entry and repeat the check on a fixed schedule, since listing status can change between reviews. Confirm the entry covers the exact data categories you transfer.

Transfer register entry

Your record of processing and transfer register should name Decision (EU) 2023/1795 as the Chapter V basis for each US flow, along with the importer's legal name, its DPF certification status and the date you last verified it. Without this entry, the file cannot show which tool made each transfer lawful. Review it whenever a new US recipient, data category or sub-processor is added, and keep prior versions so you can show what was relied on at a given date.

Importer and sub-processor terms

Hold the contract or data processing terms with the importer, plus the list of its sub-processors and the terms that flow down to them. The file should show that the importer commits to DPF obligations and to notifying you of changes in its certification. Check that the sub-processor list is current and that each entry is linked to a transfer record. Ask the importer to confirm the list in writing at each review.

Onward transfer records

Where the importer passes personal data to a third party or another country, record each onward transfer: the recipient, the country, the purpose and the safeguard that applies to it. The DPF relies on the importer to keep onward transfers under equivalent protection, so an undocumented onward flow is a gap in the file. Map these flows against the sub-processor list, because a new recipient often appears first in an engineering change rather than in a contract.

Legal status monitoring log

Maintain a dated log of changes that could affect the decision: listing changes, Commission review outcomes, the General Court judgment in Case T-553/23 and the pending appeal in Case C-703/25 P, and developments on Executive Order 14086 and Section 702 FISA. Note the date you saw each change, what it means for your transfers and who decided on any action. The log is your evidence that monitoring is active rather than occasional.

Tested fallback plan

Document a fallback for each DPF-based flow: a standard contractual clause set, supplementary measures where needed, and the steps to switch within a defined period if the decision is suspended or the importer is delisted. A plan that has never been run is weak evidence, so record a test of the switch, including who signs the clauses and where the transfer assessment is stored. Confirm the timing you can meet with your own contracting and engineering teams before you rely on it.

What relying on the DPF costs in money and effort

This table lists the cost components an exporter faces when relying on the Data Privacy Framework, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. The decision itself carries no EU filing fee for the exporter, so the real costs sit in legal review, mapping, recipient checks and contract upkeep. Use the drivers column to scope a written quote.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Legal review of the transfer basis	One-time at setup, then recurring at each review. Paid to in-house counsel or an external privacy lawyer.	Number of US importers, whether each is on the DPF List, and whether the data flow touches sensitive categories.
Transfer mapping and register upkeep	Mostly one-time build, then recurring as flows change. Paid to internal teams or an implementation partner.	Number of systems and data categories, and how often new SaaS tools or vendors are added.
Recipient verification	Recurring. Checking the DPF List and the recipient's certification status is internal effort, and recipient fees are set by the recipient.	Number of certified importers, how often certifications lapse or change scope, and whether the exporter checks manually or through tooling.
Contract and processing terms updates	One-time for template changes, recurring for each new importer or sub-processor. Paid to counsel and to internal contract teams.	Sub-processor depth in the chain, the number of data processing agreements, and whether customers require notice of changes.
Monitoring of list and legal changes	Recurring. Paid in internal staff time or to a monitoring service, and tied to the Commission review cycle and court developments.	Pending appeal developments, PCLOB and Executive Order 14086 reporting, and changes to Section 702 FISA.
Fallback clause preparation	One-time to draft, recurring to maintain. Standard contractual clauses must be ready if a DPF certification is withdrawn or invalidated.	Number of importers that would need a fallback, the transfer impact assessment depth, and how quickly the business must switch.

Who owns the transfer basis, who prepares the file, and who checks it

The organization that exports the personal data, as controller or as processor acting on instructions, owns the transfer basis. Relying on Decision (EU) 2023/1795 is a decision the exporter makes and records, and it stays accountable for that decision even when an outside party helps gather evidence. The exporter also owns the transfer register, the contracts with its importers and sub-processors, and the fallback plan if the decision is later invalidated or the importer drops off the list.

The reliance decision: Record which transfers rely on the DPF, which importers are covered, and why the decision was chosen over another Chapter V tool.
The transfer register: Keep the list of US recipients, data categories, purposes and the basis for each flow.
The contracts: Maintain the agreements that set purpose limits, onward transfer rules and the importer's commitments.
The fallback sign-off: Approve in writing the standard contractual clauses or other tool to switch to if the DPF basis fails.
The monitoring owner: Name the person who tracks the DPF List, the Commission's adequacy page and the Court of Justice proceedings.

Before relying on the DPF for any flow, confirm internally who signs the reliance decision and who receives alerts when the legal position changes.

Where organizations rely on the DPF and get it wrong

Most DPF failures are not about the adequacy decision itself. They come from weak checks on the vendor, the data and the supply chain, and from having no plan for a change in the legal picture. Each card below names one gap and the fix that closes it.

Trusting a vendor's certification claim

A vendor saying it is "DPF certified" is not evidence. Only organizations included in the Data Privacy Framework List maintained by the US Department of Commerce are covered by Decision (EU) 2023/1795. Search the List by the exact legal entity name that will receive the data, and check whether the entity in the contract matches the listed one, including subsidiaries.

Missing the verification date

Listing status can change, so a check made during procurement does not prove coverage at transfer time. Record the date you checked, the entity name as listed, the screenshot or export, and the person who verified it. Repeat the check on a schedule and before any renewal or new data flow, and keep the record with your transfer documentation.

Assuming the listing covers every data type

A DPF listing covers only the data types and HR or non-HR scope the organization selected when it certified. A company listed for customer data may not be covered for employee data. Compare the listed scope against each data flow in your records of processing, and treat any mismatch as an uncovered transfer that needs another Chapter V tool.

Ignoring sub-processors outside the US

A DPF-certified US provider may use sub-processors or support teams in other countries, and those onward transfers have their own legal basis. The adequacy decision does not cover them. Require a current sub-processor list in the processing agreement, map each location, and confirm that every onward recipient is either DPF-listed or covered by standard contractual clauses.

Having no fallback clause set

The General Court upheld the decision in September 2025, but an appeal (Case C-703/25 P) is pending, and the Commission reviews the framework periodically. If the adequacy decision were invalidated, transfers would need another tool immediately. Prepare standard contractual clauses for each US recipient in advance, with a transfer impact assessment and a named owner who can switch the flow over.

Not watching review milestones

The Commission's first review report (COM(2024) 451) set the next review after three years and listed items to monitor, including PCLOB reports, the Data Protection Review Court and possible changes to Section 702 FISA. Assign someone to track the Commission's adequacy page and the Court of Justice updates, and log any change against the affected transfers within a set internal deadline.

What buyers ask before relying on the DPF or hiring help

Does the Data Privacy Framework require a certificate from DeployOpen or an auditor?

No. The DPF is not a certification scheme for your vendors. Under Commission Implementing Decision (EU) 2023/1795, the adequacy finding covers US organizations that appear on the Data Privacy Framework List maintained by the US Department of Commerce. Your organization relies on that decision and the list when it transfers data to a participating recipient. DeployOpen does not issue reports, attestations or certificates, and no independent auditor is needed to rely on the decision. What you should check is that each US recipient is on the list and that its listing covers the data you send. Confirm the recipient's current status on the list yourself before each new transfer relationship, and keep a dated record of that check.

How much effort does the first transfer mapping take, and what drives it?

The effort depends on how many data flows cross the Atlantic and how well they are documented. The mapping step lists each flow: the exporter, the US recipient, the data categories, the purpose, the storage locations and any onward transfers to sub-processors. Costs come from the internal time of your privacy, legal and engineering staff, plus any outside help you buy. The main drivers are the number of systems and vendors, whether a record of processing already exists, and how many recipients you need to verify against the DPF List. Mapping is largely one-time work, but it must be refreshed when vendors, data types or hosting locations change. No supplied fact gives a figure for this, so ask any partner to estimate effort from a written inventory of your flows.

How long does it take to be ready for DPF-based transfers?

No fixed duration applies, because readiness depends on the scope of flows you need to cover. A company with a single US SaaS vendor on the DPF List has a much smaller task than one moving HR, customer and telemetry data to many US providers. Readiness work usually covers the flow inventory, recipient verification, contract terms with each importer and updates to privacy notices and records of processing. Ask a partner to tie its timeline to a written list of flows, systems and deliverables, and to state which items depend on your vendors or your internal approvals. Treat any date given without that inventory as an estimate to challenge.

Can our team handle DPF transfer work in-house, and what skills does it need?

Many organizations can do the core work in-house if they have the right mix of skills. The team needs someone who understands GDPR Chapter V and the difference between a DPF-covered transfer and one that needs another tool, such as standard contractual clauses. Engineering staff must be able to trace where data is stored and which systems and sub-processors touch it. Legal or privacy staff must check recipient status, contract terms and notice wording. Gaps usually appear in data flow tracing and in keeping the inventory current. The Data Privacy Framework and the adequacy decision are one part of the broader GDPR program, so check that your in-house team also covers related duties such as records of processing and data subject requests.

Does the Latombe appeal mean we must stop transfers under the DPF?

The decision itself does not require you to stop. The General Court dismissed the action for annulment in Case T-553/23 Latombe v Commission on 3 September 2025, and an appeal in Case C-703/25 P was lodged on 31 October 2025. The Commission's adequacy page still lists US DPF participants as adequate as of October 2026. Because the appeal is pending, a fallback plan is prudent. Keep standard contractual clauses or another Chapter V tool ready for key US recipients, and be able to switch the flows if the position changes. Confirm the current status of the appeal and of the adequacy page with your legal counsel before you decide, and review the position at each periodic check.

What should we ask a partner to include in a written scope?

A written scope should state exactly what the partner will prepare, what it will not do, and what you must provide. Ask for the following:

A list of systems, data flows and recipients in scope, with the platforms the partner will deploy or harden.
The deliverables, such as a flow inventory, recipient verification log, mapping workbook and updated documentation drafts.
The responsibilities split: your organization owns its controls and decisions, the partner prepares systems and evidence, and an independent auditor or certification body issues any report.
Assumptions about your input, including access to staff, vendor contracts and existing records.
Acceptance criteria, schedule milestones and the change process for scope drift.
Post-delivery support terms, if you want a retainer for refreshes.

DeployOpen works on fixed-scope engagements agreed in writing before work starts, and quotes follow from that scope.

How DeployOpen prepares transfer evidence for DPF reliance

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so the client keeps control of where personal data sits and who can reach it. We prepare the systems, configuration records and transfer evidence that a client needs to explain its reliance on the DPF, while the organization itself owns the decision and any independent assessor issues the reports.

How we scope

Confirm in writing which data flows leave the EU and whether each recipient is on the DPF List maintained by the US Department of Commerce.
Identify transfers to US recipients not on the DPF List, which need another Chapter V tool such as standard contractual clauses.
Agree deliverables, systems in scope and timelines in a fixed-scope written statement before any work begins.

How we build

Map where personal data is stored, processed and administratively accessed, including remote support from the United States.
Configure access controls, logging and key management in the client's own cloud account or data center to match the documented transfer design.
Test configurations against the client's written requirements and record the results so the client can show how its controls operate.

How we hand over

Deliver architecture diagrams, data flow maps, configuration baselines and test records for the client's compliance file.
Document each system change with the date, owner and rationale so the transfer record stays current.
Confirm with the client's counsel which evidence supports their DPF reliance, since DeployOpen does not issue legal conclusions.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately in writing.
Review the evidence set when the Commission's periodic review, the pending appeal in Case C-703/25 P or changes to US law affect the framework.
Ask your counsel and the Commission's adequacy page to confirm the current status of the decision before relying on it.