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
| Model | Who employs the staff | Who controls the network and endpoints | Main security implication |
|---|---|---|---|
| Captive centre (global capability centre) | Your own subsidiary | You | Your policies apply directly, but local employment and data law still differ |
| Dedicated ODC at a provider | Provider | Provider builds to your specification, often with dedicated bays and circuits | Contract and audit carry the controls; segregation from other clients must be proven |
| Shared delivery centre | Provider | Provider, shared across clients | Weakest segregation; rely on your VDI and identity controls, not their network |
| Build, operate, transfer | Provider, then you | Provider, then you | Transfer of accounts, assets and evidence needs planning from the start |
| Distributed remote staff via a staffing firm | Staffing firm or contractor | Often nobody: home devices | Identity 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 type | Recommended pattern | Avoid |
|---|---|---|
| Customer service and back office | VDI or web application with role-limited views, masking of card and identity numbers | Full customer record exports, bulk search |
| Application development | Cloud development environments or VDI; source in your repository with branch protection | Code cloned to provider laptops or personal repositories |
| Testing | Synthetic or masked data in non-production | Copies of production data in test environments |
| Infrastructure and cloud operations | PAM-brokered sessions, just-in-time roles, session recording | Standing admin roles, shared break-glass credentials |
| Service desk | Ticketed actions with verification workflow, no direct password resets for privileged users | Reset 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
| Threat | Example | Key controls | Framework anchor |
|---|---|---|---|
| Bribed or recruited insider | Support agents paid to copy customer records | Least-privilege views, lookup rate limits, behavioural alerts | NIST SP 800-53 PS-7 External Personnel Security |
| Provider compromise used as entry | Attacker uses provider credentials or network to reach you | Segregated network path, your own MFA, conditional access | ATT&CK T1199 Trusted Relationship |
| Impersonation of provider staff to your help desk | Caller claims to be an outsourced engineer locked out | Callback verification, manager approval for privileged resets | ATT&CK T1078 Valid Accounts |
| Data copied to provider systems | Test data or code cloned outside your environment | VDI, redirection disabled, DLP, repository controls | NIST SP 800-53 AC-20 Use of External Systems |
| Leftover access after rotation or exit | Leavers and movers not reported | Joiner, mover, leaver feed with SLA, quarterly recertification | NIST SP 800-53 AC-2 Account Management |
| Fraudulent hires | Fake identity working through a staffing firm | Identity proofing, staffing-firm audits, device and login geography checks | NIST 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
- 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.
- Reduce the data: mask, tokenise or synthesise before giving access. Every field removed is one fewer transfer and insider risk.
- 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.
- Onboard identities: connect the provider's HR feed, issue MFA authenticators on site, and run the first access review after 30 days.
- Turn on monitoring: sign-in geography, session recording for privileged work, bulk record access and repository clone alerts, routed to your SOC.
- Test: run a leaver test, a help desk impersonation test and a data exfiltration tabletop with the provider before full go-live.
- 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
| Area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| Provider risk and contracts | SA-9 External System Services; SR-6 Supplier Assessments and Reviews | GV.SC-05; GV.SC-07 | A.5.19 to A.5.22 supplier controls | Control 15 Service Provider Management |
| Offshore personnel | PS-7 External Personnel Security | GV.SC-07 | A.6.1 Screening | Control 15 |
| Remote access and external systems | AC-17 Remote Access; AC-20 Use of External Systems | PR.AA-05 | A.6.7 Remote working; A.8.22 Segregation of networks | Control 6 Access Control Management |
| Accounts and recertification | AC-2 Account Management | PR.AA-05 | A.5.18 Access rights | Control 5 Account Management |
| Physical workspace | PE-3 Physical Access Control | PR.AA-06 | A.7.1 Physical security perimeters | Not covered |
| Data leakage | AC-20; SA-9 | PR.DS-01; PR.DS-02; PR.DS-10 | A.8.12 Data leakage prevention | Control 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
- ICO: International Transfers, a Guide
- GDPR: Article 46 Transfers Subject to Appropriate Safeguards
- EBA: Guidelines on Outsourcing Arrangements (EBA/GL/2019/02)
- NIST: SP 800-53 Rev. 5
- NCSC: Principles of Supply Chain Security
- US Bureau of Industry and Security: Deemed Exports
- FBI: Public Service Announcement I-012325-PSA on North Korean IT Workers
- Microsoft Learn: Screen Capture Protection in Azure Virtual Desktop
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