Offshoring: the 8th frontier

‘Offshoring’ is a subject that conjures fear and confusion within the hearts and minds of data protection / privacy / cybersecurity professionals through to board level executives.

I spend my consulting time split between central UK government, media and fintech clients who are in very different places ranging between “I’m best friends with the Information Commissioner!” and “we’ve never realised Data Protection was a thing — but we’re not really going to change what we do or how we do it because what you’re saying sounds like a lot of work and/or has a negative sales/marketing consequence in our eyes.”

Offshoring is ‘easier’ than people think and the answers to the questions raised by offshoring are nearly entirely met by information you should (must) already have from the other questions you must already be asking — when, who, why, what, how etc (just without the ‘where’)

TL;DR – If you have reasonably done what Data Protection Legislation requires: you can probably ‘just’ offshore.

For the vast majority of circumstances, offshoring is mainly a legal issue (of which risks are entirely proportional and manageable – even in the face of Brexit).

You’re probably already offshoring even if you think you aren’t (seriously!)

Defining ‘offshoring’

Offshoring is more than just the processing of personal data abroad it is also about direct and indirect supply chain.

(I have previously written about application code supply chain risks although that post did not consider the legal position nor threat actors — because it did not need to)

Data protection definition

‘Offshoring’ is not used as an actual term within relevant data legislation or regulation.

The General Data Protection Regulation (GDPR) (EU) 2016/679 discusses transfers to third countries (or international organisations) in Chapter 5 (Articles 44 to 50). The UK’s Data Protection Act (DPA) 2018 re-uses the GDPR definitions and makes direct references to the GDPR.

The data protection definition of offshoring boils down to the processing of personal data outside of the countries that the organisation and data subject are based in (involving a third country) — such processing is considered an international transfer.

Within the scope of GDPR, transfers within the EU aren’t considered international transfers (offshoring)— you could call this ‘near-shoring’ for fun.

Supply chain definition

My definition of supply chain offshoring: any performance or provision that occurs or stems from outside of the ((name of your country))

Supply chain offshoring can be quite complex but there is no reason to panic as in most cases it does not require special attention before the offshoring considerations around Personal Data, therefore answers you should already have.

You will be acutely aware if you have other burdens from say additional regulatory requirements, your intellectual property value requires greater levels of paranoia or your threat model reasonable says so — sure it a little James Bond to think Hostile State Actors want your data but you’re going to burn a lot of time/money/effort out of hubris trying to defend against such threat actors when they may not even know/care you exist.

So, when am I offshoring?

Michael described six questions he thought organisations should ask themselves to identify offshoring (whether Personal Data is in scope or not) during a cross UK government working group on offshoring:

• data hosting — where is my data located in terms of servers and storage (probably in a data centre) including offsite backup locations?
• data processing — for example data being held in a database in the UK, but
  outsourced service contract (for example, a support call centre) that can view, modify, copy or delete the data is operating remotely
• development of service — who does the development? are they in another country?
• the operation of your service itself — similar to data processing, who is
  managing your service as you may have system administrators who are global and work on a follow the sun shift.
• the operation of the data hosting itself — for example Microsoft Azure’s data centre is in the UK but the system admins can be located in New Zealand, China, Brazil, US and so on.
• where are these legally instantiated and located? — just because Amazon Web Services have a UK data centre this doesn’t mean they’re not still a US company also with global support offices.

Offshoring Examples

(The next section is ‘Offshoring risks’ if you want to skip the examples.)

Personal Data on/near/off-shoring examples

Onshore example:

• Data Subject is in the UK
• Organisation is solely (legally incorporated, all staff etc) based in the UK.
• The Data Subject fills in a paper form they were given in the organisation’s office and simply hands it in. The organisation just files in on-site and staff pull the paper out from time to time.

Near-shoring example:

• Data Subject is in Italy (an EU member state)
• Organisation is solely (legally incorporated, all staff etc) based in France (another EU member state)
• The organisation’s supply chain includes a German company which processes personal data in Germany (for example, a data-centre provider or call centre)

This constitutes near-shoring but does not require any special data processing addendum or considerations due to countries involved being inside the EU.

Offshoring example #1:

• Data Subject is in Italy
• Organisation is solely based in France (legally incorporated, all of their own staff etc)
• The organisation uses Amazon Web Services (AWS) for web hosting and choose the AWS EU ‘regions’ (at present: London, Frankfurt or Ireland data-centres)
• AWS is an organisation legally based in the United States (overall consideration including the subsidiary structure) and has operational support staff across the globe

This does constitute offshoring through the involvement of AWS, a US-based company. A foreign legal jurisdiction has been involved, even if you take a balanced view that their international operational support staff will not access your data on a routine basis (we can discuss probability of this another time)

Offshoring example #2:

• Data Subject is in Italy
• Organisation is solely based in France
• The organisation uses a call-centre based in the US that uses local staff for out of hours customer service who have access to customer accounts (etc) to provide said customer service

This does constitute offshoring through the use of the US-based call-centre. This offshoring example is less opaque as it is clear there is a US legal entity with US staff processing Personal Data on a routine basis.

Supply chain offshoring examples

Software example #1:

• An organisation in the UK retains an Indian software development firm to create an application for them

This constitutes an off-shored supply chain as a foreign legal organisation with foreign staff are developing software which the UK organisation will execute.

Software example #2:

• An organisation in the UK uses a popular open source package published to github.com. While likely opaque in the real world, the developers are based abroad and/or the open source foundation acting as maintainer is abroad.

This constitutes an off-shored supply chain as direct influence is possible from another legal jurisdiction (particularly pertinent when a formed organisation is involved, over just an individual or collection of individuals all acting separately). This is one of the hardest off-shored supply chain webs to untangle.

I have a post on the back-burner about how you deal with these kinds of concerns, however for the moment my post on application development supply chain risks will have to suffice.

Hardware example:

• An organisation in France purchases a Huawei router for their corporate network.

This constitutes an off-shored supply chain as Huawei is a foreign company and the device is manufactured abroad.

I gave this hardware example for obvious simplicity but this isn’t a risk or political commentary — flags are a poor indicator for trust.

Offshoring risks

Data protection

Offshoring the processing of personal data happens a lot and I would argue it is now the default in our XaaS age.

When a Data Controller offshores directly or through supply chain (Data Processors chain) the organisation must consider and ensure the rights and freedoms of the Data Subject ranging from the safe keeping of data (encryption and what have you), the ability to obey/action requests (right of erasure and so on) through to an appropriate legal mechanism for the data transfer.

The Data Controller and Data Processor are responsible in different ways for keeping data safe — the burden is always there regardless whether any offshoring is taking place or not.

The risks with offshoring data incorrectly or inappropriately is that Data Controllers cannot assert they have taken appropriate and adequate measures to keep data safe and/or they are unable to obey the requests of the Data Subject — ultimately this leads to reputational damage and/or fines.

Supply chain

The risks from an offshored supply chain are often identical to an inshored supply chain —am I receiving a high-quality service? is my intellectual property/data safe? what happens if my supplier goes under? can the supplier hike their prices without notice?

The supply chain risks start to matter when you have justifiable concerns over intellectual property or negative influence — in government and military spaces, this is usually when assurances are unclear and cannot determine to your required level of probability that the supply chain is not creating risks to your systems and data.

The UK’s National Cyber Security Centre (NCSC) have discussed supply chain risks in cloud-enabled products.

Offshoring risk mitigation

Data protection

When you consider what the Data Controller must always do at all times, the offshoring element tends to be a legal and contractual consideration more than anything else.

The European Commission has taken various third country (outside of EU) adequacy decisions so that EU countries using these particular third countries need not go through particularly taxing lengths to assure the offshoring aspect of the data processing is legal or safe (oppressive regime in terms of privacy rights etc)

If you’re outside of the EU or the adequacy decisions do not apply (you’re offshoring to a country not on that list) then you must likely place a focus on formal promises (contracts et al) — particularly data sharing addendums through Model Clauses aka Standard Contractual Clauses… and as described above, continue to do the things required whether offshoring or not: risk assessments (can the supplier be reasonably asked and reasonably evidence they can keep data safe) and so on.

Supply chain

For the vast majority of cases, you do not need to worry about supply chain assurances beyond what you would do for Personal Data or operational due diligence.

This type of risk mitigation — where reasonably (you’re not being all James Bond for fun) justified by your threat model etc — simply requires attention to detail and a corresponding level of due diligence.

There will be no shortcuts, but as you start to pull on threads and apply methodologies you will identify risks and controls (and so on) like you would in many other assurance tactics.

I’m starting to panic, what does this all mean and what do I need to do?

It is highly unlikely that you need to worry about supply chain assurances beyond what you would do for Personal Data or operational due diligence.

Unless you know otherwise, focus on your existing DPA/GDPR work and a good level of focus on your Data Processors and subsequent Sub-Processors (if any).

The supply chain offshoring importance in your context should be led by your industry and what your organisation does — in most cases, it will be unreasonable to expel a significant amount of effort on understanding nuanced supply chain (without the involvement of Personal Data) as the associated risks and threats are unlikely.

The letter to Permanent Secretaries from the CEO of the NCSC discussed national security (in the UK, this is the SECRET classification and above) as the line in the sand above which the risks and threats matter.

Earlier you wrote ‘answers you should already have’

A large part of the ‘pain’ I saw with organisations implementing GDPR was that they were never truly compliant with previous legislation/regulation.

The 8th principle of the UK Data Protection Act 1998 was:

Personal data shall not be transferred to a country or territory outside the European Economic Area, unless that country or territory ensures an adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data

For over 10 years (at least) organisations have been required to understand if they are offshoring Personal Data and ensure that they are doing so legally and in a way that keeps the data adequately safe.

GDPR didn’t make offshoring any harder or riskier — a good summary page of GDPR’s inclusions of this.

I think I have intellectual property and/or non-personal data assets which warrant a good look at my offshore supply chain

Are you sure? Are you really sure?

The long and short of it is that you have a fair amount of work to do, but pending on your level of distrust or suspicion you should start with a methodical mapping exercise and go from there. It is also probable you lack the expertise to cover this off by yourself.

Mythbusting: Does the GDPR require EU personal data to stay in the EU?

No!

I have people within my organisation that just don’t ‘get’ offshoring and don’t think we should do it

It is worth reminding them (or just sending them the link to this post) that offshoring is much much more than where bits and bytes are stored on hard drives even though this is (sadly) an extremely common misunderstanding.

Organisations likely find themselves offshoring data all the time, whether through their email services and other IT tooling through to their use of platforms like Slack, Trello, AtlassianCloud, Amazon Web Services, Google Cloud Platform and Microsoft Azure — even if UK data centres are chosen.

Committing to only onshore processing is incredibly difficult in this modern interconnected technology age but is also committing to not leveraging useful commodity platforms/services and the efficiencies they can bring (time, money, effort, error, security and risk).

My advice is to take a step back and use a more balanced overarching view to understand that in many cases the difference with offshoring is largely a legal one and that legal burden does not have a very high or difficult bar and while one could argue the severity of these informational and legals risks they are usually (nearly always) worth taking for the technological efficiency, functionality, simplicity, price (and so on).

I am a Data Controller in the UK and I am unsure of what to do in the face of a ‘no-deal’ hard Brexit!

In my view after considering the limited published guidance says:

• you should ensure you understand the scope of your data processing/sharing, what your Joint Data Controllers or Data Processors do for you and how they behave (retention, Sub-Processors etc) and so on (this should be a ‘check’ anyway!)
• ensure you have scoped and executed ‘Standard Contract Clauses’ (the new name for Model Clauses) — ICO link
• think about where you rely on Binding Corporate Rules — ICO link

This applies particularly if you rely on the EU-US Privacy Shield mechanism (read: EU27-US Privacy Shield) given the UK’s departure — see this update from European Scrunity Commons Select Committee which advises EU-US Privacy Shield participants to update their public commitment to explicitly included data from the UK.

The crux of my thinking here is that you are a Data Controller in the UK so while you should taper off relying on EU27-US Privacy Shield and must consider the EU27 offshoring (where before it was effectively no difference ‘near-shoring’ when the UK was in EU28) nothing else has fundamentally changed — the US can still be a ‘safe place’ to offshore Personal Data to and the EU27 still have the might of GDPR.

While I am not a lawyer, and not have not engaged with the ICO over this post: in my view, the ICO is highly unlikely to take enforcement action against you as long as you have made all reasonable efforts to comply with the total spirit and burden of the Data Protection Act (2018) even if your legal offshoring mechanism lapses due to the UK’s departure from the EU as long as you have considered it and have a reasonable plan to remedy it.

Should I inshore data just incase?
No. This is highly disproportional and expensive to do and your chance of actual success is low given what the definition of offshoring actually is (as above: data storage or technical processing locations are not the totality of offshoring)

For an example of how difficult and disproportional this would be: if you used Microsoft Office 365 or Google G-Suite for emails/documents you would have to find an inshored service and then migrate every document and email account!

You might find other exciting posts in my Medium profile. I’m on Twitter as @JoelGSamuel.