Challenging Conventional Wisdom
Many believe that if your non-EEA processor employs remote workers in third countries, you've created a new cross-border data transfer chain needing additional mechanisms. Privacy teams often treat each remote employee location as a separate transfer, requiring its own Standard Contractual Clauses, adequacy assessment, or supplementary measures analysis.
This approach can lead to complex compliance matrices. For instance, if your processor operates from Singapore, with a developer in Vietnam and a support analyst in Thailand, you're managing three distinct cross-border transfers. Each demands documentation, risk assessment, and possibly separate contractual instruments.
A Different Perspective
Processor employees aren't separate data importers; they're part of the processor's measures for delivering services. When you engage Processor Z under Article 28 GDPR, you're authorizing them to process data on your behalf. Where their employees are physically located is an internal detail, not a new transfer requiring oversight under Chapter V.
This distinction affects your compliance burden. If remote workers are separate transfers, you'd need:
- Individual transfer impact assessments for each location
- Separate Standard Contractual Clauses or adequacy determinations
- Ongoing monitoring of each jurisdiction's surveillance laws
- Documentation updates for employee relocations
If remote workers are part of the processor's security measures, your task is simpler: verify that the processor's remote-access controls meet Article 32 requirements and that your Article 28 contract ensures appropriate safeguards, regardless of employee location.
Supporting Evidence
Article 28(3)(a) GDPR requires processors to ensure that those authorized to process data "have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality." This treats employee access as a security control issue, not a transfer issue.
EDPB Guidelines clarify that a processor acts "on behalf of" the controller. The processor's internal operations, including staff locations, fall under their compliance obligations, not the controller's transfer obligations.
Consider this: engaging a cloud provider with data centers in Frankfurt doesn't create a separate transfer each time an engineer accesses your data. The same logic applies when that engineer works remotely from Portugal or Morocco.
Regulatory agencies, like the Federal Trade Commission, focus on whether processors implement adequate security measures, not on whether controllers document every employee's location as a separate transfer.
Practical Steps for Compliance
Your Article 28 contract should treat remote access as a security requirement:
Implement Location-Agnostic Security Controls. Require the processor to use multi-factor authentication, encryption, access logging, and role-based permissions, regardless of employee location. These controls are more important than geographic documentation.
Audit the Processor's Remote-Work Policy. Ensure the processor mandates secure home networks, prohibits public Wi-Fi for data access, requires encrypted devices, and enforces screen-lock policies. These are Article 32 measures and your legitimate oversight concern.
Include Remote Access in Your Vendor Questionnaire. Ask about security controls for employee access from remote locations, not a list of every country where employees might work.
Document Security Commitments, Not Locations. Your processing record under Article 30 should note that Processor Z implements safeguards for remote access. You don't need a sub-processing notification for every employee move.
Verify the Processor's Transfer Compliance. If Processor Z transfers data to a sub-processor in a third country, it requires your prior authorization under Article 28(2). But a remote employee isn't a sub-processor.
When Conventional Wisdom Applies
The analysis changes if the remote worker isn't an employee of your contracted processor. If Processor Z subcontracts activities to independent contractors or third-party providers in other jurisdictions, you're dealing with sub-processing that requires Article 28(2) authorization and possibly new transfer mechanisms.
Conventional wisdom also applies if the processor's remote-work policy is so weak that employee location becomes a risk. If your processor allows unencrypted devices, doesn't enforce VPN use, or lacks adequate access controls, then employee locations represent unmitigated risks that might trigger your obligations under Article 32.
For special-category data under Article 9 or data subject to sector-specific restrictions, your risk tolerance for remote access should be lower. In such cases, limiting processing to specific jurisdictions might be justified, not because remote workers are transfers, but because the sensitivity demands tighter controls.
The key question isn't "Where do the processor's employees work?" It's "Does the processor implement security measures that adequately protect the data regardless of employee location?" Answer that, and you'll focus more on actual security oversight than on mapping employee movements.
