Vietnam has no EU adequacy decision, so any personal data your organisation sends to a Vietnam-based development team is a restricted transfer under GDPR Chapter V, full stop. That means you cannot rely on the vendor's ISO 27001 certificate or a signed NDA alone.
You need a legal transfer mechanism, usually Standard Contractual Clauses (SCCs), a Transfer Impact Assessment (TIA) that looks honestly at Vietnamese law, and a Data Processing Agreement (DPA) that says exactly where the data sits and who can touch it. This article walks through that sequence in the order a DPO or legal counsel will actually want to see it done, and what to ask for in writing versus what a vendor can tell you verbally.
This article is informational and does not constitute legal advice. Data transfer law changes by jurisdiction and by the nature of the data involved; confirm your specific transfer mechanism with your own counsel or DPO before signing anything.
TL;DR
Vietnam has no EU adequacy decision, so transfers there require a safeguard mechanism under GDPR Article 46, in practice the Standard Contractual Clauses.
For a controller engaging an offshore developer as a processor, that means SCCs Module 2 (controller to processor), not Module 1 or 3.
A Transfer Impact Assessment is mandatory post-Schrems II and, for a normal software engagement, is a bounded document, not an open-ended legal review.
Vietnam's own Personal Data Protection Law and Decree 356/2025/ND-CP, in force since January 1, 2026, add a domestic layer: Vietnam has its own rules on cross-border transfer and impact assessment that your vendor must also satisfy on their side.
The engineering fix that actually reduces your exposure is architectural: keep production personal data on EU-hosted infrastructure, give the offshore team masked or synthetic data in non-production environments, and scope access by environment rather than by trust.
About the author: 724SOFTWARE is a Vietnam-based engineering partner holding ISO 9001 and ISO 27001:2022 certification, SOC 2 Type II attestation, and GDPR compliance, delivering dedicated development teams and offshore development centres for clients including regulated fintech and healthcare platforms across 10+ countries. The company structures engagements so production personal data can remain on client-controlled infrastructure while development happens through masked or synthetic datasets, and has executed SCC and DPA agreements with European clients across multiple sectors.
Why Does Vietnam Not Have an EU Adequacy Decision, and What Does That Actually Change?
An adequacy decision is the European Commission's formal finding that a non-EU country's data protection law is "essentially equivalent" to the GDPR; once granted, personal data can flow to that country the same way it flows within the EEA, no extra paperwork required. Vietnam has not received one .
Practically, this means every transfer of personal data from your organisation to a Vietnam-based team needs its own legal basis under GDPR Article 46, most commonly Standard Contractual Clauses or Binding Corporate Rules. It does not mean the transfer is illegal or unusually risky by default. It means the compliance burden shifts from "check the adequacy list" to "build and document a safeguard yourself." Buyers who skip this step are not failing an audit because the vendor was insecure; they are failing it because no transfer instrument was ever signed.
There is a second, less obvious layer here. Vietnam's own Law on Data (No. 60/2024/QH15, effective July 1, 2025) and the Personal Data Protection Law with its implementing Decree 356/2025/ND-CP (effective January 1, 2026) impose domestic cross-border transfer obligations on the Vietnamese entity itself, including a requirement to file a cross-border transfer and processing impact assessment with the Ministry of Public Security. This is not your obligation as the EU exporter, but it is worth confirming your vendor has it in hand, because a vendor who has not addressed their own domestic transfer filing has a compliance gap that will eventually touch your data too.
Which SCC Module Applies When You Hire an Offshore Developer?
The Standard Contractual Clauses come in four modules depending on the relationship between exporter and importer; picking the wrong one is the most common mistake in this kind of contract. When a European company (controller) engages a Vietnam development team to build or maintain software using the controller's data, the correct instrument is SCC Module 2 (controller to processor)
Module 2 requires you to complete several annexes, not just sign a template:
Annex I describes the parties, the categories of data subjects, the categories of personal data, the purpose of processing, and the retention period.
Annex II specifies the technical and organisational security measures the importer commits to.
Annex III, where relevant, lists authorised sub-processors.
The work here is filling these annexes out accurately for your specific engagement, not the act of signing. A generic annex that says "all personal data, all purposes" is the kind of gap a security reviewer will flag immediately, because it gives you no way to later prove the transfer was proportionate
What Is a Transfer Impact Assessment, and How Much Work Does It Really Take?
A Transfer Impact Assessment (TIA) is the documented analysis, required after the Schrems II ruling, of whether the destination country's laws could undermine the protections the SCCs are supposed to guarantee, and what supplementary measures close any gap. For a typical software development engagement, this is a bounded exercise, not a research project.
A practical TIA for a Vietnam engagement should cover:
What data is actually being transferred. Most development work does not need production personal data at all; scope the assessment to what will genuinely cross the border.
Vietnam's legal environment for government access to data, referencing the current PDPL and Decree 356/2025/ND-CP framework
The safeguard mechanism in place (SCCs) and whether it is sufficient on its own or needs supplementing.
Supplementary technical measures, such as encryption in transit and at rest, pseudonymisation, and environment-based access restriction.
A documented conclusion, dated and signed off internally, that the residual risk is acceptable given the measures in place.
Most DPOs can complete this in a few hours once the vendor has answered the data-mapping questions. The effort balloons only when the vendor cannot say clearly what data will be visible to which engineers in which environment, which is exactly the ambiguity a well-run offshore partner should be able to close in one call.
What Must the Data Processing Agreement Actually Contain?
A Data Processing Agreement under GDPR Article 28 is the contract that turns your processor's obligations into enforceable terms, and it needs to say more than "we take security seriously". For an offshore development engagement, the DPA should specify:
Clause | What to require
|
|---|---|
Purpose limitation | Data used only for the specified development or support work, no secondary use |
Retention | A defined retention period, tied to the project or contract term |
Deletion on exit | A contractual deadline (e.g. 30 days) for deletion of all copies after contract end, with written confirmation |
Audit rights | Your right to audit or commission an audit of the processor's controls |
Breach notification | A specific timeline (commonly 24-72 hours) for the vendor to notify you of a suspected breach |
Sub-processor approval | Prior written notice and your right to object before a new sub-processor is engaged |
The sub-processor clause is the one buyers most often gloss over, and it is where the actual risk usually hides. Your development vendor's own cloud provider, CI/CD tooling, and any third-party monitoring or AI-assisted coding tools are all sub-processors if they touch personal data. Ask specifically which cloud region hosts any environment containing real data, and whether any tooling sends code or data outside that region. A vendor who cannot answer this in writing has not mapped their own data flows, which is a bigger problem than any certificate on their website solves.
What Engineering Controls Actually Reduce the Transfer Footprint?
The single most effective way to reduce transfer risk is architectural, not contractual: minimise how much real personal data ever needs to leave the EEA in the first place. This is the point buyers underuse most.
Pseudonymise or mask data in non-production environments. Developers rarely need real names, national IDs, or account numbers to build and test features; replace them with synthetic or masked equivalents before the dataset reaches the offshore team.
Keep production data on EU-hosted infrastructure. Structure the architecture so the offshore team develops and tests against non-production environments while production personal data remains on infrastructure located in the EEA, accessed only through controlled, logged interfaces when strictly necessary.
Scope access by environment, not by individual trust. Engineers should get access to staging and test environments by default; production access should require a separate, logged, time-boxed approval, regardless of how senior or trusted the engineer is.
Write the infrastructure commitment into the contract itself: name the cloud regions where production data will reside, state that development and QA use de-identified data, and require written notice before that architecture changes.
What Should You Require in Writing Versus Accept Verbally?
Require in writing: the SCC module and completed annexes, the DPA with the clauses above, the vendor's sub-processor list, the completed TIA, and the infrastructure and data-residency commitment. Accept verbally, at most, as a starting point for due diligence, but always convert into the DPA before signing: general descriptions of team structure, working hours, or internal review processes. If a vendor is reluctant to put the data flow, sub-processor list, or deletion timeline in writing, treat that as the answer.
A Practical Sequence to Follow
Map exactly what personal data the engagement requires, and confirm whether production data is needed at all.
Confirm the vendor's ISO 27001:2022, SOC 2 Type II, and GDPR compliance status, and request their sub-processor list.
Execute SCC Module 2 with fully completed Annexes I-III.
Complete a Transfer Impact Assessment covering Vietnam's legal environment and your supplementary measures.
Negotiate the DPA: purpose limitation, retention, deletion on exit, audit rights, breach notification timeline.
Confirm in the contract where production data is hosted (ideally EEA) and that offshore access is limited to masked or synthetic data outside production.
Review and re-approve annually, or whenever the vendor changes cloud provider, sub-processor, or tooling.
Frequently Asked Questions
Does Vietnam having no adequacy decision mean we cannot send data there at all?
No. It means you need an approved transfer mechanism, typically SCCs, plus a Transfer Impact Assessment. Plenty of European companies run this process routinely.
Which SCC module do we use for a development vendor?
Module 2, controller to processor, is the standard fit when you control the data and the vendor processes it on your instructions.
Do we need a TIA for every project, even small ones?
Yes in principle, but the scope should match the data involved. A project using only synthetic test data still needs a short assessment; one involving live customer data needs a fuller one.
What does Vietnam's own data law require from the vendor?
Since January 1, 2026, Vietnam's Personal Data Protection Law and Decree 356/2025/ND-CP require Vietnamese entities handling cross-border transfers to file impact assessments with the Ministry of Public Security. Confirm your vendor has this in hand as part of due diligence.
Can the offshore team just use masked data and avoid this entirely?
Masking reduces the scope of your TIA and DPA considerably, but if any real personal data ever crosses the border, even for debugging, the transfer mechanism still needs to be in place.
Does an ISO 27001 certificate replace the need for SCCs?
No. ISO 27001:2022 Annex A Control 5.14 requires the vendor to have formal transfer policies and agreements in place, which supports your case, but it does not substitute for the legal transfer mechanism GDPR requires.
Is any of this specific to 724SOFTWARE, or does it apply to any Vietnam vendor?
The legal framework applies to any transfer to Vietnam, regardless of vendor. What differs between vendors is how cleanly they can answer the sub-processor, data-residency, and access-control questions above, which is where due diligence time actually goes.
About 724SOFTWARE
724SOFTWARE is a Vietnam-based technology partner delivering dedicated development teams and offshore development centres for European, Australian, and APAC clients, certified to ISO 9001 and ISO 27001:2022, SOC 2 Type II attested, and GDPR compliant. The company structures engagements so production personal data can remain on client-controlled infrastructure while development happens through masked or synthetic datasets, and has executed SCC and DPA agreements with clients across fintech, healthcare, and other regulated sectors. Learn more at https://724software.com.vn.
