The reach of GDPR doesn’t stop at the borders of Europe. Using non-European cloud platforms and Software-as-a-Service from within Europe just got a lot more complicated.

Data Protection and Cybersecurity

Data protection and cybersecurity are different, but related topics. Cybersecurity is the collection of technologies, controls, and behaviors that combine to form an organization’s response to the risk of cyberthreats. Cybersecurity means keeping the bad guys out and the data in.

Data protection is the suite of governance and controls—mainly, policies and procedures—designed to safeguard personal data and ensure it is used within the letter of the law.

Some of the safeguarding requirement is satisfied by your cybersecurity measures, and that’s the point where data protection and cybersecurity intersect. Safeguarding also means making sure your staff don’t leak data through simple mistakes like sending a spreadsheet to the wrong recipient. And that’s where your data governance policies and procedures come into play.

How those documents are structured and which measures they must enforce is driven by the laws and regulations that you must adhere to. That is established by local legislation which in turn is a function of geography and politics.

Businesses that employ cloud computing can be based thousands of miles away from their line of business applications, data, and servers. A company based in Europe, for example, might make use of a service physically sited in a data center in the United States.

Transferring personal data to non-European countries is complicated. And it just got more complicated.

GDPR

The General Data Protection Regulation 2016 became enforceable in 2018.

What the GDPR is concerned with is the processing, storage, and transmission of personal data, or personally identifiable information (PII). Processing means performing any action on or with personal data. Running a complicated SQL query to extract records matching a certain demographic, or sending a single email to a single recipient are both examples of processing.

There is a legal requirement for organizations that process, store, or transmit personal data to apply satisfactory governance and safeguards on the data. The purpose of that requirement is to protect and uphold the rights and freedoms of the data subjects—the people that the data belongs to.

That’s a very fast run through—the GDPR is 88 pages of terse bureaucracy. There’s a lot of it, a lot to it, and the devil is in the details.

Personal Data

Personal data is any information relating to an individual whether it relates to his or her private, professional, or public life. That’s a massive scope. It can be anything from a name, a home address, a photo, an email address, bank details, posts on social networking websites, medical information, a computer’s IP address, and so on.

And you don’t need to hold enough information to identify a person for it to be classed as personal data. It’s like a digital jigsaw. If hold a single piece of the jigsaw that could be used with the other pieces—even if they have to be sourced elsewhere—to identify a person, your single piece of information is classed as personal data and must be treated in accordance with the GDPR.

Actually, It’s Global

The biggest myth with GDPR is that it only applies to the member states of the European Union and it’s something only European organizations have to deal with.

The reality is, if you employ Europeans, have any premises in Europe, trade with European companies or citizens, the GDPR applies to you. The GDPR is a regulation that protects European citizens and their personal data and it applies to any organization that processes any personal data belonging to Europeans. That’s how Google was fined over USD 50 million.

There are a few exemptions. Non-European businesses of fewer than 250 employees must still safeguard the data and use it in accordance with the GDPR, but they are spared a bit of the paperwork and recordkeeping.

And the word belonging is an interesting one in this context.

We’re used to thinking along the lines of my database, my spreadsheet, my mailing list, and so on. And that’s correct, they’re yours. But if my data is in any of your digital systems, legally it is my data and you have a copy of it. It isn’t your data. It’s mine. And I have data subject rights dictating what you can and cannot do with that data.

Gone are the days when you could harvest data without a care, do what you wanted with it, and could share it with whom you saw fit. Now, you need a lawful basis even to collect the data in the first place, as well as a lawful basis to process it.

Crossing Borders

The GDPR says you can only transmit personal data to other countries if they are:

In the European Union In the European Economic Area Have their own data protection legislation in place that the European Commission, taking into account the findings of the European Data Protection Board, has judged to be adequate. These rulings are called adequacy decisions.

If you’re not in the European Union, nor the European Economic Area you’re classed as a third country.

So far Andorra, Argentina, Canada, the Faroe Islands, Guernsey, Israel, the Isle of Man, Japan, Jersey, New Zealand, Switzerland, and Uruguay are third countries with adequacy decisions.

Personal data can be transmitted to any of these third countries where it will be processed, stored, and transmitted with the same degree of safeguarding and governance as if it were being handled in a region subject to the GDPR.

Two names are missing from that list. Conspicuous by their absence are the United States, and the United Kingdom.

The UK and Brexit

The United kingdom is in the process of transitioning out of the European Union. If the United kingdom leaves the European Union without a trade deal allowing it to remain a functioning member of the Economic European Area, it will become a third country, and will require an adequacy decision on a suitable data protection framework and legislation.

The United kingdom does have legislation ready for this. Chapter Two of the United kingdom’s Data Protection Act 2018 contains (more or less) the whole of GDPR. So the legislation is ready, it is already enshrined in British law, and it must surely be adequate because it is the GDPR.

The trouble is, the adequacy decision process is very slow.

The US and Privacy Shield

The United States has a partial adequacy decision. The EU-U.S. and Swiss-U.S. Privacy Shield Frameworks were designed by the U.S. Department of Commerce, the European Commission and the Swiss Administration to provide an acceptable mechanism for the transfer of personal data between the European Union, Switzerland and the United States.

The United States was awarded a partial adequacy decision because Privacy Shield isn’t country-wide legislation and it isn’t mandatory. Organizations decide whether they need to participate or not. It’s opt-in.

Actually, it’s more accurate to say that the United States had a partial adequacy decision.

Schrems 2

The Privacy Shield framework worked well. It allowed American cloud platform providers and Software-as-a-Service companies to trade in Europe and to service European customers even though their data centers may have been located in the United States.

It worked well that is, until Maximillian Schrems, an Austrian data protection activist, brought a case to the Court of Justice of the European Union (CJEU). He won the case, and a judgement was made by the CJEU on July 16, 2020. This was followed by a position statement from the Swiss Federal Data Protection and Information Commissioner.

The case boiled down to whether the Privacy Shield framework was sufficiently robust to warrant even a partial adequacy decision. By winning the case, Privacy Shield was invalidated.

Part of the case hinged on the United States’ mass data gathering and surveillance initiatives such as PRISM and UPSTREAM, and the ability of the National Security Agency and other similar agencies to request customers’ personal data from American companies.

Now What?

Large organizations like Google and Microsoft have data centers strategically positioned in different regions such as Europe, Africa, the Middle East, and Asia. This is done specifically to service those regions from within those regions. But having data centers in Europe doesn’t overcome the issue. The NSA can still force them to hand over the data, regardless of the location of the data center. Simply having a data center in Europe doesn’t solve anything.

So to sum up, the United States is a third country without an adequacy decision and it seems extremely likely that the United Kingdom will shortly be in exactly the same position.

There will not be a straightforward means for the transfer of personal data between European companies and British or American companies. Even within an international corporation, or group of companies, moving data from an office in Europe to a branch in London or New York will be complicated.

But there has to be some way for a European company to be able to send data to a third country without an adequacy decision. The European Data Protection Board surely couldn’t expect GDPR to drop like a guillotine to sever existing business ties to, for example, the Middle East?

In fact, provisions exist for that very contingency. They are:

Derogations Codes of Conduct and Certification Mechanisms Binding Corporate Rules Standard Contractual Clauses

That’s something. But even so, it won’t be plain sailing.

Derogations

Derogations are country-specific deviations from the letter of the GDPR that have been approved by the European Commission and the Supervisory Authority of the country in Europe. Each business must forward its own case.

Derogations allow a degree of flexibility in certain conditions and are a condoned and justified departure from the usual requirements. Unfortunately, they must be applied restrictively, and they cannot become the norm. They are by definition the exception to the rule. Additionally, they relate to “processing activities that are occasional and non-repetitive.”

So, derogations are impractical for regular business transfers of personal data.

Codes of Conduct and Certification Mechanisms

The European Data Protection Board say that Codes of Conduct and Certification Mechanisms can offer appropriate safeguards for transfers of personal data to third countries if there are binding and enforceable commitments on the company in the third country.

Associations and professional bodies may prepare codes for approval and registration. Article 42 of the GDPR states “data protection certification mechanisms, seals or marks … may be established for the purpose of demonstrating the existence of appropriate safeguards provided by controllers or processors that are not subject to this Regulation.”

A tremendous amount of work would have to go into such a scheme.

A suitable code of conduct and certification mechanism would have to be developed by trade associations or professional bodies in the third country. The code would need to be appraised and approved by the European Data Protection Board. Businesses represented by the trade association or body in the third country would need to adopt the code, and be able to evidence their compliance. The participating businesses would need to be examined and, if they pass, certificated. That requires the establishment of a certification body. The participating businesses would then need to be monitored to ensure ongoing compliance with the code.

There are no approved codes of conduct in the United States nor in the United Kingdom, although the United Kingdom’s Information Commissioners’ Office says they have processes in place to accept applications. Don’t expect a fast turnaround.

Binding Corporate Rules

Binding Corporate Rules are internal rules which define the international policy in multinational groups of companies and international organizations regarding cross-border—but still within the same organization—transfers of personal data.

Binding corporate rules are detailed and comprehensive, and very similar to contracts. There is a standard set of information and topics which are mandatory for inclusion. Binding corporate rules have to be submitted for review and authorization by the Supervisory Authority of the European country.

Binding Corporate Rules are complex and time-consuming to create but for a multinational or large international organization, they will simplify data transfers greatly once they are implemented.

Standard Contractual Clauses

Both the European company and the company in the third country must agree to use a contract of standard contractual clauses approved by the European Commission. These contracts provide additional data protection safeguards that are required in the case of a transfer of personal data to any third country.

The standard contractual clauses must be signed by both parties. If they are not signed, they are not considered as being in place.

Standard contractual clauses may be included in a wider contract and additional clauses might be added, so long as they do not contradict, directly or indirectly, the standard contractual clauses. You can’t add clauses to the contract to try and override any requirements of the standard contractual clauses that you don’t like.

You can modify the standard contractual clauses to take into account a specific or particular situation. Once they have been changed, of course, they are no longer standard contractual clauses. They become ad hoc contractual clauses and before they can be used they must be authorized by the European company’s data protection Supervisory Authority.

The European Commission has produced sets of standard contractual clauses, and out of the four available options, they do seem to be the best general solution.

Is That the Solution?

Some Software-as-a-Service providers have included standard contractual clauses in their terms and conditions. But will their wording satisfy the demands of the European Commission? Another issue is the signature. The service providers are hoping that your agreement to their terms and conditions will stand in lieu of a signature.

It might well require a test case to set a precedent before this becomes clear.