Data residency and the EU buyer.

Two things, mostly. First, a valid transfer mechanism for any personal data leaving the EEA — either an adequacy decision (the EU-US Data Privacy Framework, the UK adequacy, Switzerland, and a shrinking list of others), Standard Contractual Clauses with a completed Transfer Impact Assessment, or Binding Corporate Rules. SCCs are the workhorse; nobody executes BCRs for a dev shop engagement. Second, a full picture of who touches the data — a written subprocessor list, notification rights when it changes, and a data processing agreement (DPA) under Article 28 that binds the offshore agency to the buyer's controller obligations.

"Data stays in the EEA" is not one of the two things GDPR requires. It is a stricter posture some buyers adopt to avoid ever having to fill out the first requirement, and to keep the DPO's quarterly review boring. When a buyer writes residency into the SOW, they are not enforcing GDPR. They are enforcing a policy that makes GDPR easier to enforce, which is a different question.

Offshore agencies routinely respond to a residency clause with "we'll execute SCCs, is that fine." It is not fine. SCCs are the legal mechanism for a transfer the buyer has accepted. Residency is a promise that no transfer occurs in the first place. A buyer who wrote residency into the SOW is telling you their compliance program is not set up to review individual transfers case-by-case, and asking to substitute SCCs is asking them to redo that program for your engagement.

The correct response is either to meet the residency clause (EEA-region cloud, EEA-based tooling, no laptops outside the EEA touching customer data) or to negotiate a scoped exception with the specific tool named — for example, an SCC-covered exception for a US logging provider, with a clear boundary on what data flows to it. The exception has to be written before signature, not after the DPO's Q2 review.

First, saying the data is in the EEA when your CI pipeline runs on a us-east-1 runner that briefly holds environment variables containing production credentials. Second, saying no non-EEA staff have access when a founder or CTO in a non-EEA country has org-admin on the cloud account. Third, saying the subprocessor list is complete when Slack, Notion, Google Workspace, and GitHub are all on it as tools but none of them are named as subprocessors of personal data — even though customer email addresses show up in support Slack channels. Fourth, saying encrypted-at-rest solves the residency question — it does not; the encrypted bytes are still in the wrong region.

Every one of these is fixable before signature. None of them is fixable at the DPO's quarterly review without a breach notification. The gap between the SOW paragraph the buyer wants and the actual operational posture the agency runs is where the deal breaks. Close it in writing at kickoff, not by inference.

"All Personal Data processed under this engagement will be stored and processed in the European Economic Area, other than as expressly listed in Annex A (Transfer Exceptions), which is limited to [named tool, named data field, named legal basis]." This is the residency line, with named exceptions instead of a generic escape hatch. It survives a DPO review.

"Vendor's subprocessors are listed in Annex B and will be updated within five business days of any addition; Buyer has a right to object within thirty days." This is the subprocessor line, and it is what Article 28 actually asks for. "No Personal Data will be accessed from workstations outside the EEA without prior written approval and technical controls preventing local storage." This is the laptop line, and it is the one that catches the offshore agency's non-EEA staff.