UK GDPR when your development team works outside the UK

Separate the role, the route and the access

UK GDPR treats these as three different questions. Most overseas arrangements answer one of them well and assume the other two follow.

The compliance stack for an overseas team

For a restricted transfer the route is UK adequacy regulations, an appropriate safeguard, or a limited exception. Article 46 safeguards include the ICO’s International Data Transfer Agreement (IDTA) and the UK Addendum to the EU Standard Contractual Clauses. Either way a transfer risk assessment, now the “data protection test” in the legislation, has to be completed and its extra protections implemented. The ICO says the current IDTA and Addendum remain in use while the 2026 refresh following the Data (Use and Access) Act 2025 is prepared. ICO: rules on appropriate safeguards · ICO: the IDTA and Addendum

What UK clients actually ask an overseas team for

For this guide we went back through our own UK engagement records from 2022 to 2026: briefs, tenders, proposals and delivery channels. Client names are withheld. The pattern is more practical than the legal literature suggests.

1. Nobody asked for an IDTA or the Addendum by name. They asked for a DPA, dummy data, database-level roles and access reviews. The transfer mechanism is still the controller’s obligation under Chapter V, so a supplier that raises it unprompted lowers everyone’s risk.
2. “Database level, not UI level” is the test that matters. A client who asks you to run a direct query with the support credentials and show it returns nothing sensitive has understood the problem better than most vendor questionnaires.
3. Access removal has to be scheduled, not remembered. Super-admin off at sign-off, a narrower support role afterwards, a review every six months.

A real boundary: a UK energy broker’s ERP, built from India

Since 2023 our India-based team has built and run the ERP for a leading UK energy broker: clients, contacts, addresses, meter points, supplier tenders, contracts, brokerage accounting, half-hourly consumption, invoice validation and an S3 document vault, in one Laravel system with role-based access for administrators, operations staff and partner brokers.

The hard decision was consolidation versus exposure. Moving the operation out of spreadsheets and inboxes created a coherent system of record and concentrated data that used to sit apart. The answer was role-aware access: a partner broker sees their slice, not the administrator’s. The same rule extends to development and support. A person debugging an importer does not need the full contact, contract and document view.

Score the exposure before granting access

The Production Access Exposure Score is our triage model for a proposed development or support workflow. It does not decide whether a transfer is lawful. It tells the product owner how urgently to shrink the technical exposure before anyone gets access.

A named engineer viewing a status and an error code for two hours scores two or less. The same engineer with standing database-admin access, exports and customer documents scores seven or more. Same business problem, different exposure.

A data-light delivery path and an exceptional production path

This makes the lower-risk path the fastest path. Developers reproduce validation, import and rendering faults with representative fixtures. When a production-only problem genuinely needs a record, the team requests a short-lived grant against a named client, purpose and field list. The gateway owns the query and the audit event. The engineer never receives a reusable database credential.

type SupportSession = {
  engineerId: string;
  clientId: string;
  purpose: "incident" | "data-correction" | "release-check";
  approvedBy: string;
  expiresAt: Date;
  fields: Array<"accountRef" | "status" | "postcodeArea" | "errorCode">;
};

const SAFE_FIELDS = new Set(["accountRef", "status", "postcodeArea", "errorCode"]);

export async function readSupportRecord(session: SupportSession, recordId: string) {
  if (session.expiresAt <= new Date()) throw new Error("Grant expired");
  if (!session.approvedBy) throw new Error("Approval required");
  if (session.fields.some((f) => !SAFE_FIELDS.has(f))) {
    throw new Error("Field is outside the support allow-list");
  }

  // The query is built from a fixed server-side allow-list, never user input.
  const select = Object.fromEntries(session.fields.map((f) => [f, true]));
  const record = await db.customerAccount.findFirst({
    where: { id: recordId, clientId: session.clientId },
    select,
  });

  await db.productionAccessEvent.create({
    data: {
      engineerId: session.engineerId,
      clientId: session.clientId,
      recordId,
      purpose: session.purpose,
      approvedBy: session.approvedBy,
      fields: session.fields,
      grantExpiresAt: session.expiresAt,
      occurredAt: new Date(),
    },
  });

  return record;
}

In production, connect the gateway to the identity provider, require phishing-resistant MFA for privileged roles, send approvals to a different person, prevent arbitrary query construction and alert on bulk reads. Keep the log itself minimal: who, why, which record, when. Not another copy of the data.

Failure modes that appear after the paperwork is signed

A DPIA is required where processing is likely to be high risk, and the same discipline is useful for any new production-access path: describe the processing, assess necessity, identify harm, mitigate before launch. ICO: what is a DPIA?

Recommendations by business type

Primary sources

• ICO guide to international transfers
• ICO restricted-transfer three-step test
• ICO controller-processor contract requirements
• ICO appropriate-safeguards rules
• ICO IDTA and Addendum guidance
• ICO data-security outcomes
• ICO DPIA guidance

Technical and operational guidance, not legal advice. Have the final arrangement reviewed by a qualified UK data-protection professional.