Join our Newsletter — 33% off our NHI Course
Home› Guides› Offshore Delivery Centre Security Guide: Access, Data Residency…
Guide Third-Party & Supply Chain Risk

Offshore Delivery Centre Security Guide: Access, Data Residency and Workspace Controls for Offshore Teams

PDF for newsletter subscribers · free to read online

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 11 November 2026 14 min read
On this page

An offshore delivery centre puts hundreds of people who are not your employees, in a building you do not control, under a legal system that is not yours, inside your production systems and customer data. Offshore and nearshore delivery centres (ODCs) run application development, testing, infrastructure support, service desks and customer operations for organisations of every size, either through an outsourcing provider or a captive centre the organisation owns. The security model has to cover four things at once: who the people are, how they reach your systems, where your data goes and which laws then apply, and what the physical workspace allows. This guide is for security architects, third-party risk managers, privacy teams and delivery leads who set up, audit or exit an ODC.

Key takeaways

  • Remote access from abroad is a data transfer. The UK ICO says making data accessible to a controller or processor outside the UK results in a restricted transfer, even if the data never leaves UK servers, so an offshore support team viewing a database needs a transfer mechanism.
  • Keep data in your environment, not theirs. Delivery through virtual desktops with clipboard, drive and printer redirection disabled keeps data on your side and makes offboarding a single switch.
  • Identity is your control, not the provider's. Named accounts in your directory, phishing-resistant MFA and joiner, mover and leaver feeds from the provider beat shared logins and provider-managed access.
  • People risk is the biggest risk. Bribed or impersonated support staff caused some of the most costly recent incidents; screening, role-limited data views and monitoring matter more than the firewall.
  • Plan the exit on day one. Financial regulators expect a documented exit plan for critical outsourced functions, and every account, key and copy of data at the ODC has to be traceable for that to work.

Delivery models and what changes

ModelWho employs the staffWho controls the network and endpointsMain security implication
Captive centre (global capability centre)Your own subsidiaryYouYour policies apply directly, but local employment and data law still differ
Dedicated ODC at a providerProviderProvider builds to your specification, often with dedicated bays and circuitsContract and audit carry the controls; segregation from other clients must be proven
Shared delivery centreProviderProvider, shared across clientsWeakest segregation; rely on your VDI and identity controls, not their network
Build, operate, transferProvider, then youProvider, then youTransfer of accounts, assets and evidence needs planning from the start
Distributed remote staff via a staffing firmStaffing firm or contractorOften nobody: home devicesIdentity verification and endpoint control are hardest; fraud risk highest

The further right the provider's control extends, the more your protection depends on contract terms, evidence and your own access architecture. For the general third-party access lifecycle, see the Third-Party Access Guide.

Access architecture: how offshore staff reach your systems

  • Virtual desktop delivery: staff work in a VDI or desktop-as-a-service session hosted in your tenant. Data stays in your environment and access ends when the account is disabled. See the Virtual Desktop (VDI) and DaaS Security Guide.
  • Redirection off by default: disable clipboard, drive and printer redirection for ODC host pools. Microsoft's Azure Virtual Desktop documentation notes that screen capture protection does not stop clipboard or drive copying, so these must be switched off separately.
  • Screen capture protection and watermarking: Azure Virtual Desktop offers "Block screen capture on client" and "Block screen capture on client and server" options. Microsoft states it does not prevent phone photos and recommends watermarking with a QR code that traces the session to discourage them. Other VDI platforms have equivalent features.
  • Managed or locked-down endpoints at the ODC: thin clients or hardened laptops with USB storage blocked, local admin removed and only the approved VDI client installed. The FBI's 2025 public service announcement on North Korean IT workers specifically advises limiting who can install remote desktop software.
  • Network path: a dedicated circuit, IPsec tunnel or SD-WAN link from the ODC to your environment, terminating in a segment that only reaches the VDI gateway, not your internal network. Conditional access should accept sign-ins only from the ODC's egress addresses or compliant devices.
  • Privileged work: infrastructure and database administration through brokered, recorded sessions with just-in-time elevation. See the Vendor Privileged Access Management (VPAM) Guide.

Choosing the access pattern

Work typeRecommended patternAvoid
Customer service and back officeVDI or web application with role-limited views, masking of card and identity numbersFull customer record exports, bulk search
Application developmentCloud development environments or VDI; source in your repository with branch protectionCode cloned to provider laptops or personal repositories
TestingSynthetic or masked data in non-productionCopies of production data in test environments
Infrastructure and cloud operationsPAM-brokered sessions, just-in-time roles, session recordingStanding admin roles, shared break-glass credentials
Service deskTicketed actions with verification workflow, no direct password resets for privileged usersReset authority without callback or manager approval

Where identity fits

The single biggest design choice is whose directory the offshore staff live in. Accounts in your identity provider, created from a joiner feed the provider must keep current, give you MFA policy, conditional access, logging and one-click revocation. Provider-managed accounts federated in can work for large captive-style arrangements, but only if the contract requires leaver notification within an agreed time and you can still see and disable individual users.

  • Named accounts only: no shared team logins, even for shift-based support.
  • Phishing-resistant MFA: FIDO2 keys issued at the ODC are practical because staff work from a controlled site.
  • Movers: staff rotating between client accounts in a shared centre are the classic source of leftover access. Require the provider to report moves, not just leavers.
  • Non-human identities: offshore development teams create service accounts, API keys and pipeline tokens. Require registration of each in your inventory with an owner who is your employee, so they survive the end of the contract in a known state. See the Contractor Identity Lifecycle Guide.

Data residency and cross-border law

Offshore delivery is international data transfer, and in regulated sectors it is regulated outsourcing as well.

  • UK GDPR: the ICO's international transfers guide states that making data accessible to a separate controller or processor outside the UK results in a restricted transfer, and gives the example of an IT support team in India accessing data on UK servers. Mechanisms are UK adequacy regulations, the International Data Transfer Agreement (IDTA), the International Data Transfer Addendum to the EU standard contractual clauses, and UK binding corporate rules. Before relying on an Article 46 mechanism you must complete a transfer risk assessment.
  • EU GDPR: Article 46(2) lists the appropriate safeguards, including binding corporate rules and standard data protection clauses adopted by the Commission. See the Standard Contractual Clauses (SCCs) Guide.
  • Financial services outsourcing: the EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) require institutions to record the country where a service is performed and where data is located, to secure audit and access rights over providers, and to keep a documented exit plan for each critical or important function.
  • Export controls: releasing controlled technology or source code to staff abroad can be an export. Under the US Export Administration Regulations, the Bureau of Industry and Security treats even a release to a foreign person within the United States as a "deemed export". Classify the technology before offshoring engineering work. See the Encryption Export Controls Guide.
  • Destination-country law: the ODC's own country may impose data localisation, government access powers or breach reporting duties. For India, see the India DPDP Act Guide; for wider context, the Data Sovereignty and Residency Guide.

The practical rule: map each ODC work stream to the data categories it can see, record the transfer mechanism and risk assessment for each, and reduce what is visible (masking, synthetic test data) before relying on legal mechanisms.

People and workspace controls

  • Screening: background checks to an agreed standard, contractually required and evidenced by sampling, not attestation alone. See the Personnel Security and Background Screening Guide.
  • Remote hiring fraud: the FBI warns that North Korean IT workers have used AI and face-swapping in video interviews, and advises auditing third-party staffing firms' hiring practices and doing as much onboarding in person as possible. See the Insider Threat from Fake IT Workers Guide.
  • Dedicated bays: access-controlled floor areas for your work, with badge logs, CCTV coverage of entrances and visitor escort. In shared centres, require physical separation from other clients' teams for sensitive work.
  • Clean desk and device rules: no personal phones or recording devices in high-sensitivity bays, no printing, no paper. Common in payment card and health data work; enforce with lockers at the bay entrance.
  • Insider monitoring: alert on unusual record views, bulk lookups and access outside shift patterns. Make it known that monitoring exists; the deterrent matters.
  • Incentive risk: lower-paid support roles with access to valuable data are bribery targets. Limit what any single agent can see and how much they can look up per shift.

Threats and controls at a glance

ThreatExampleKey controlsFramework anchor
Bribed or recruited insiderSupport agents paid to copy customer recordsLeast-privilege views, lookup rate limits, behavioural alertsNIST SP 800-53 PS-7 External Personnel Security
Provider compromise used as entryAttacker uses provider credentials or network to reach youSegregated network path, your own MFA, conditional accessATT&CK T1199 Trusted Relationship
Impersonation of provider staff to your help deskCaller claims to be an outsourced engineer locked outCallback verification, manager approval for privileged resetsATT&CK T1078 Valid Accounts
Data copied to provider systemsTest data or code cloned outside your environmentVDI, redirection disabled, DLP, repository controlsNIST SP 800-53 AC-20 Use of External Systems
Leftover access after rotation or exitLeavers and movers not reportedJoiner, mover, leaver feed with SLA, quarterly recertificationNIST SP 800-53 AC-2 Account Management
Fraudulent hiresFake identity working through a staffing firmIdentity proofing, staffing-firm audits, device and login geography checksNIST SP 800-53 PS-7

Contract, assurance and exit

  • Security schedule: name the controls in this guide in the contract: screening standard, access pattern, device standard, leaver notice period, incident notification time, right to audit and right to monitor.
  • Sub-outsourcing: require notice and approval before any part of the work moves to a subcontractor or another delivery location. The EBA guidelines require advance notification of sub-outsourcing for critical or important functions.
  • Evidence: independent assurance reports scoped to the actual delivery centre, plus your own sampled tests: pick ten leavers and confirm their accounts were disabled on time. See the How to Read a SOC 2 Report Guide.
  • Supply chain programme: the NCSC's 12 supply chain security principles group the work into understanding the risks, establishing control, checking your arrangements and continuous improvement, which is a useful structure for ODC governance.
  • Exit: a written exit plan covering account removal, return or certified deletion of data, transfer of code and documentation, rotation of every credential the ODC staff knew, and knowledge transfer. Rotate secrets even where staff "never had access": shared runbooks spread them.

Implementing it: phased approach

  1. Classify the work: list each work stream, the systems and data categories it needs, and whether it is critical or important under any outsourcing rules that apply to you.
  2. Reduce the data: mask, tokenise or synthesise before giving access. Every field removed is one fewer transfer and insider risk.
  3. Build the access path: VDI host pool, conditional access policy, network path and PAM integration. Pilot with one team in audit mode: log clipboard and file transfer attempts before blocking them, then switch to block.
  4. Onboard identities: connect the provider's HR feed, issue MFA authenticators on site, and run the first access review after 30 days.
  5. Turn on monitoring: sign-in geography, session recording for privileged work, bulk record access and repository clone alerts, routed to your SOC.
  6. Test: run a leaver test, a help desk impersonation test and a data exfiltration tabletop with the provider before full go-live.
  7. Rollback: keep onshore capability or a second provider able to take critical work back while the ODC is proven.

Small versus large organisations

A small company using a handful of offshore developers through a staffing firm cannot audit a facility. It should concentrate on accounts in its own directory, MFA, cloud development environments, repository controls and identity verification at hiring. Large enterprises with dedicated centres should add contractual audit rights, physical bay controls, dedicated circuits and a captive or second-source exit option.

Detection and metrics

  • Leaver latency: time from the provider's leaver date to account disablement; target agreed in contract, measured monthly.
  • Orphaned access: number of ODC accounts with no matching active record in the provider feed.
  • Anomalous access: sign-ins from outside the ODC egress addresses, multiple logins to one account from different countries (a warning sign the FBI highlights), and access outside shift hours.
  • Data movement: blocked clipboard, file transfer and print attempts per user, and repository clones to unmanaged locations.
  • Lookup volume: records viewed per agent per shift against the team baseline.
  • Assurance coverage: percentage of ODC work streams with a current transfer risk assessment and a tested exit plan.

Common failure patterns

  • Broad data views for support agents: in the Coinbase insider breach, criminals bribed overseas outsourced support agents to copy data on 69,461 customers, then demanded a ransom.
  • Help desk trusts a caller claiming to be supplier staff: the Marks and Spencer cyberattack began with attackers impersonating a third-party user.
  • Provider-managed shared accounts: you cannot tell who did what, and leavers keep working credentials.
  • Production data in offshore test environments: masked data was planned, then dropped for a deadline, and never removed.
  • Transfer assessed once: the transfer risk assessment covered the original scope, but the ODC later took on new data categories.
  • No credential rotation at exit: accounts are disabled, but the shared secrets in runbooks and pipelines are not rotated.

Framework mapping

AreaNIST SP 800-53 Rev. 5NIST CSF 2.0ISO/IEC 27001:2022 Annex ACIS Controls v8.1
Provider risk and contractsSA-9 External System Services; SR-6 Supplier Assessments and ReviewsGV.SC-05; GV.SC-07A.5.19 to A.5.22 supplier controlsControl 15 Service Provider Management
Offshore personnelPS-7 External Personnel SecurityGV.SC-07A.6.1 ScreeningControl 15
Remote access and external systemsAC-17 Remote Access; AC-20 Use of External SystemsPR.AA-05A.6.7 Remote working; A.8.22 Segregation of networksControl 6 Access Control Management
Accounts and recertificationAC-2 Account ManagementPR.AA-05A.5.18 Access rightsControl 5 Account Management
Physical workspacePE-3 Physical Access ControlPR.AA-06A.7.1 Physical security perimetersNot covered
Data leakageAC-20; SA-9PR.DS-01; PR.DS-02; PR.DS-10A.8.12 Data leakage preventionControl 3 Data Protection

Practitioner checklist

  • Map every ODC work stream to the systems and data categories it can see, and cut that set before go-live.
  • Record the transfer mechanism and transfer risk assessment for each work stream, and review them when scope changes.
  • Deliver work through VDI or cloud development environments in your tenant with clipboard, drive and printer redirection disabled.
  • Keep ODC staff as named accounts in your directory with phishing-resistant MFA and conditional access tied to ODC egress or compliant devices.
  • Contract for joiner, mover and leaver feeds with a deadline, and test them by sampling.
  • Broker all privileged work through PAM with just-in-time elevation and session recording.
  • Limit per-agent data views and lookup volumes, and alert on bulk access.
  • Require approval before sub-outsourcing or moving work to a new location.
  • Verify identity during remote hiring and audit staffing firms' screening.
  • Keep a tested exit plan that includes rotating every credential the ODC could have known.

Standards and references

Related NHI Mgmt Group resources: Third-Party Access Guide · Vendor Privileged Access Management (VPAM) Guide · Data Sovereignty and Residency Guide · Insider Threat from Fake IT Workers Guide · Virtual Desktop (VDI) and DaaS Security Guide

PDF for subscribers

Take this guide with you

Every section, table and checklist in one PDF, with links to the sources and related guides. Subscribe to our weekly NHI & AI Identity Journal and we’ll email you a download link.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 11 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org

PDF Downloads for Newsletter Subscribers

Get the guide

Enter your details and we’ll email you a download link.

The full guide is free to read online. The PDF is a thank you for subscribing.

Fill in all fields marked * and tick the PDF box to continue.