Data security across distributed engineering teams

Distributing engineering across countries changes the security question from who is trusted to what each person can reach. An engineer in another jurisdiction is subject to a different legal regime, works on a device outside the corporate estate, and reaches systems over a network the organisation does not control. The controls that carry a co-located team are largely physical and cultural, and neither transfers.

This article sets out the three management models we encounter, the control set each one requires, and the checks that confirm the standard is held.

The management model determines the control set

Team extension

Offshore engineers work inside the client organisation's repository, issue tracker and review process as additional members of an existing team. Accountability stays with the client's engineering management. This model places the security burden on identity and authorisation, because the offshore engineer reaches client systems directly. It is the model we use most often, and the most straightforward to audit, since every action appears in the client's own logs under a named identity.

Autonomous pod

A self-contained team owns a service or a product area, with its own backlog, its own review process and a defined interface to the rest of the estate. Accountability sits with a named lead on the supplier side. This model reduces the number of client systems the team reaches, and moves the exposure to the interface between the pod's environment and the client's. The security work concentrates on that boundary: how code moves across it, how it is reviewed before it does, and what data flows back.

Follow the sun

Work passes between locations across a day, usually for operational cover or incident response. This model demands the highest standard because the handover is routine and the privileges tend to be elevated. An on-call engineer needs production access, and production access held by a rotating group across jurisdictions is the largest single exposure in distributed delivery. It requires just-in-time elevation with an expiry, a recorded reason for each grant, and session recording on privileged access.

The controls that do the work

Across all three models the same six controls account for most of the risk reduction, in this order:

• One identity provider, phishing-resistant. Every engineer authenticates through the client's identity provider with hardware-backed or platform passkeys. Shared accounts and supplier-managed credentials remove the audit trail every other control depends on. Joiner and leaver processing runs in one place, so an engineer rotating off loses access on the day.
• Least privilege, reviewed quarterly. Access scoped to the repositories, environments and datasets a role requires. Standing production access granted to a development team is the finding we report most often, and it is usually a residue of an initial migration rather than a current need.
• No production data in development. The control with the largest effect and the one most often deferred. Synthetic or masked datasets for development and test remove whole categories of exposure, including the exposure created by a laptop in a jurisdiction with different legal protection. Where a defect can only be reproduced on real data, it is reproduced in a controlled environment with access logged and time-boxed.
• Managed device posture. Disk encryption, screen lock, patch currency and endpoint protection verified at the point of access rather than asserted in a policy document. Conditional access that evaluates device state is what converts the policy into a control.
• Network and session control. Access to non-public environments through an identity-aware proxy or a zero-trust broker rather than a flat corporate VPN. A VPN that places an offshore laptop on the internal network grants far more reach than the work requires.
• Logging the client retains. Authentication, authorisation changes, repository events and production access recorded in a system the client owns, with retention set to the longer of the regulator's requirement and the contract term. Logs held only by the supplier are of limited value at audit.

Residency applies to the development estate

Data residency obligations are generally assessed against production systems. They apply equally to anything holding a copy of regulated data, which includes development databases, test fixtures, defect attachments, log aggregation and backups. A development environment outside the permitted region holding a restored production snapshot is a residency breach, and a common one. Our note on UAE PDPL data residency sets out where those copies accumulate.

Removing production data from development resolves the residency question and the access question together, which is why it sits above device and network controls in the order above. Where regulated data must remain in region, the practical arrangement is remote access into an in-region environment with no local copy, enforced by blocking download and clipboard egress rather than by instruction.

An organisation able to state, for any engineer, which datasets they could reach yesterday and which they actually did has the distributed security problem under control.

Contractual and personnel controls

Technical controls need matching commercial terms. The agreement should name the processing locations and require notice before any change, place confidentiality and intellectual property obligations on the individual engineer as well as the supplier, define background check standards and the evidence for them, set breach notification inside the window the client's own regulatory obligation requires, and grant audit rights over the supplier's controls. Where personal data crosses a border, the transfer needs a lawful basis documented before the first engineer is onboarded.

For Saudi engagements the National Cybersecurity Authority Essential Cybersecurity Controls apply to the supply chain as well as to the entity, so a supplier's controls form part of the entity's own compliance position. ISO 27001 certification at the supplier is evidence of a management system rather than evidence of the controls on your programme, and the control set above is what should be confirmed directly.

Confirming the standard holds

Four checks establish the real position, and each is answerable from system records rather than from a questionnaire: produce the current list of identities with access to production and the business justification for each; show that the last engineer to rotate off lost access on their final day; name the dataset used in the development environment and demonstrate it carries no production records; and retrieve the access log for one named engineer for one named day. An organisation that can complete all four has the controls in place. One that cannot has a policy.