# DPAs, data terms and procurement: what FDEs need to know so projects don't stall in legal

> A pipeline that works can still stop because legal emails one question: where does the customer's data go, who holds it, and for how long? That only becomes a problem if you don't already have the answer.

Bản gốc: https://fdetimes.net/en/guides/dpa-data-terms-procurement-for-fdes/

Picture your third week on a customer site. The pipeline runs well on sample data, and you want to try a different model provider for summarising support tickets. The customer's engineers agree straight away. Then an email arrives from legal with a single question: is this provider on the approved subprocessor list?

This is the kind of blocker that doesn't live in the code. You don't need to become a lawyer. But you are the person touching the customer's data directly, so you need to be able to read the clauses that decide what you are allowed to touch.

This article teaches one specific skill: reading a DPA as you would read a spec, and having answers ready for vendor review before the customer asks.

## The data contract is your scope of work

In GDPR terms, the customer is the controller and your company is the processor. Article 28 of the GDPR requires the processor to process personal data only on the documented instructions of the controller.

Vietnamese law sets out an almost identical requirement: the processor must process data in line with the agreement or contract signed with the controller.

The practical consequence is simple. Whenever you run a script on real data, export a table to debug, or send a piece of text to an external API, first ask whether it falls within the contract. Only then ask whether it works.

And the "contract" has to be written down: the GDPR requires the processing agreement to be in writing, which can include electronic form. Four clauses in a DPA bear directly on engineering work.

**Subprocessors.** The processor may not engage another processor without the controller's prior written authorisation, whether specific or general.

**End of service.** All personal data must be deleted or returned, at the customer's choice.

**Audit.** The customer has the right to audit, including on-site inspections.

**Transfers abroad.** If data leaves the EU, safeguards are needed, such as Standard Contractual Clauses (SCCs): model clauses pre-approved by the European Commission.

**Điểm mấu chốt:** Before asking whether the script runs, ask whether the contract allows you to run it.

## A worked example: adding a model provider mid-project

Back to legal's email. Suppose the customer is an EU retailer and the provider you want to try hosts its servers outside the EU. Here is how to handle it, step by step.

First, establish whether the new provider counts as a new processor. If you send tickets containing customer names and emails to its API, the answer is yes. That means you need the customer's written authorisation. Check whether the current DPA gives general authorisation with a subprocessor list, or requires case-by-case approval.

Second, the transfer abroad. Servers outside the EU mean a transfer to a third country, so legal will ask about SCCs. You can answer quickly if you know how the provider's DPA works.

Take Anthropic as an example: according to its help page, accepting the Commercial Terms of Service also means accepting Anthropic's DPA, which includes SCCs, with no separate signing step. Sending legal a link to that clause is far faster than promising to chase a signature.

Third, retention. The buyer will ask how long the provider keeps data. Apptension's due diligence guide is blunt: if a vendor cannot show clear retention controls, assume the data will be kept longer than you want. Have the answer before you walk into the meeting.

The last step, and the one most often forgotten, is the end of the project. The obligation to delete or return data does not apply only to the main database. It also covers the CSV you extracted to debug, the notebook on your laptop and the logs containing raw ticket text.

The table below is a data-flow map for exactly this scenario:

| Data | Stored in | Processed by | Region | Retention | At end of project |
|---|---|---|---|---|---|
| Original tickets | Customer DB | Customer | EU | Per customer policy | Customer keeps |
| Ticket text sent for summarisation | New provider's API | Subprocessor (pending approval) | Outside EU, SCCs needed | Ask provider | Delete per DPA |
| Debug extracts | FDE's machine | Your company | Wherever the machine is | Until end of sprint | Delete and record the deletion |
| Application logs | Logging system | Your company | State the region | Set a TTL | Delete or return |

The second row is precisely the question legal sent. With this table, you can answer in one email instead of three meetings.

## If the customer is in Vietnam, the project timeline gains new milestones

First, separate old from new. Vietnam's Personal Data Protection Law took effect on 1 January 2026, accompanied by Decree 356, issued on 31 December 2025 to guide its implementation, replacing the earlier Decree 13 framework.

For your project plan, the new framework adds the following.

**The 60-day milestone.** According to a DLA Piper summary, a data processing impact assessment (DPIA) dossier is required, and the authorities must receive it within 60 days of processing starting. Put it in the rollout plan as a real milestone.

**The six-month cycle.** According to analysis by Tilleke & Gibbins, the new law requires both the DPIA and the cross-border transfer impact assessment (TIA) to be updated on a six-month cycle if anything changes. Adding a model provider based abroad is exactly that kind of change.

**Risk on transfers abroad.** Breaches of the cross-border transfer rules can be fined up to 5% of annual revenue. So tell the customer early whenever a data flow changes direction.

**Your side's paperwork.** Under Decree 13, the processor also had to prepare and keep its own impact assessment dossier, as the controller did, and transfers abroad needed a separate dossier filed with the Department of Cybersecurity. The old rules have been replaced, so ask the customer's legal team which dossiers your side is responsible for under Decree 356.

## What vendor review will ask, and why you should answer first

Procurement at large companies usually includes a round of vendor review. According to Apptension's guide for buyers, that review should start with data flows and retention.

Vendors that cannot answer clearly get placed in the high-risk bucket. The same guide notes that if you cannot name subprocessors and data regions, you cannot convincingly answer the question of where data goes when you are audited.

The question that most often stalls a review is the scope of the SOC 2 report. A SOC 2 report is only valid for the products and environments listed in its scope section.

Apptension's advice is that the way to de-risk a SOC 2 review is to read the scope section first. If you are deploying a dedicated environment for the customer and the report covers only the shared SaaS offering, that is a gap to raise before the customer finds it.

## Steps to follow, and common mistakes

With every new customer, follow a fixed order. Request the DPA and the subprocessor list in week one, then draw the data-flow map before touching real data. Flag every external tool that will receive data, put milestones such as subprocessor approval and the DPIA dossier into the plan, and write a data deletion checklist for handover day in advance.

The most common mistake is treating legal as someone else's job. The result is an FDE adding an observability tool or a new API simply because a customer engineer said yes out loud.

The next is forgetting that logs and extracted files are personal data too. Another is handing over a SOC 2 report without knowing which product it covers.

## Turn it into an interview story

When reading FDE job descriptions, watch for phrases such as security review, procurement or customer compliance: if they appear, this skill belongs on your CV. And when you are asked about a deployment that got stuck, the example above is good material.

One concise way to tell it: in week three, the customer's legal team blocked adding a summarisation provider because it was not on the subprocessor list and its servers were outside the EU. You built a six-column data-flow map, sent a link to the provider's DPA with SCCs, set a TTL on the logs and wrote a checklist for deleting debug files.

The outcome: the customer approved by email, with no extra meeting. The story shows you understand both sides of a deployment.

Next time the customer's legal team sends a question, answer with a table that has all six columns, not with a promise.

**Thử ngay tuần này:**

- Take your current project and draw a six-column data-flow map: data type, storage location, who processes it, region, retention period, deletion method. Mark the cells you cannot yet fill in.
- Find the DPA or data processing terms that apply to the customer. Underline the subprocessor list and compare it with the tools you are actually using.
- Open the SOC 2 report for the product you are deploying and read the scope section first. Note which products and environments it covers.

## Nguồn

- [Art. 28 GDPR – Processor - General Data Protection Regulation (GDPR)](https://gdpr-info.eu/art-28-gdpr/)

- [Standard Contractual Clauses (SCC)](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en)

- [How do I view and sign your Data Processing Addendum (DPA)?](https://privacy.claude.com/en/articles/7996862-how-do-i-view-and-sign-your-data-processing-addendum-dpa)

- [Data protection laws in Vietnam (Data Protection Laws of the World, DLA Piper)](https://www.dlapiperdataprotection.com/?c=VN&t=law)

- [Vietnam's New Personal Data Protection Law: A Closer Look](https://www.tilleke.com/?p=68543)

- [Vietnam: Decree 13 and the new regulations on personal data protection](https://www.dlapiper.com/en-au/insights/publications/crossroads-icr-insights/2023/vietnam-decree-13-and-the-new-regulations-on-personal-data-protection)

- [Enterprise Vendor Due Diligence Checklist for Software and AI](https://apptension.com/guides/enterprise-grade-vendor-due-diligence-checklist-for-software-and-ai)