Are Security and Privacy the Same Thing?

Many businesses use Cloud-based Software-as-a-Service (SaaS) providers, such as Google Drive, Box, Dropbox, etc., to store important data. Lately, I’ve had more than one conversation with clients about some important considerations for using those services now that GDPR is in full effect. What trade-off is it to use them? What they offer vs. what they take away in the context of control is worth thinking about for a moment, especially if it could cost us up to 4% of our annual revenue if we’re found to be out of compliance with the GDPR.

The question I am being asked more and more is this: “Is this a potentially avoidable mistake?”

“A Shared Responsibility”

Let’s use Google Drive as an example because it’s popular with businesses of all shapes and sizes for the way it stores files accessible from any device or platform from anywhere in the world to work in a collaborative and friendly way that many other tools cannot match. Its functionality, convenience, ease-of-use, and cost make it a popular choice, especially for small and medium-sized organizations, which is why they need to be advised about Google’s business model and what it may mean for them in the context of compliance with evolving local and international privacy law. This is why Google and others use somewhat slippery language in their Terms of Service agreements, stating compliance is a “shared responsibility”. What does that mean, exactly? It’s anyone’s guess at this point.

Are Privacy and Security the Same Thing?

In light of Facebook’s ongoing controversy, another platform that uses data to profile users and build more effectively targeted advertising, putting our data in the hands of Cloud-based SaaS providers should raise questions about protecting data and privacy.

Here’s what Google Drive does well – encryption tools to help keep data secure:

As data leaves any device, it’s encrypted using current TLS standards before it’s uploaded to Google Drive..

Once that data arrives at Google, it’s decrypted and then encrypted, again, using 128-bit AES, rather than the 256-bit version, which is fine for most data but not for all, especially Restricted levels of data classifications.

Encryption is done in transit before the data is stored in Drive, which is good because it helps prevent leaks of unencrypted data.

AES encryption keys used to encrypt the data are then also encrypted with a regularly rotating set of keys, adding another layer of protection.

The whole process is reversed whenever we retrieve data from our Google Drive.

Other, good data protection features of Google Drive:

Multi-factor authentication is supported and can be enforced for all users across an organization. This is non-negotiable these days as passwords, alone, are easily circumvented.

Metadata, or information that describes our information, is also encrypted while stored.

Our data is also encrypted when moved internally. For example, when we move a file from one location (or folder) to another, all data is encrypted in transit inside Google’s network. This is important because data is often moved around data centers from one side of the world to another.

Google does a good job of protecting our data, which is also in their best interests, but where it get fuzzy is the way they like to interchange the words “security” and “privacy“.

For the uninitiated, these aren’t always the same thing, especially not to the GDPR, for example. Using them in this way, in legal terms that people agree to, is on the dicey side and can easily mislead those of us less fluent in these concepts. Please be aware!

Privacy and Security Aren’t the Same Thing

From the moment we begin to use it, Google Drive (Docs, Sheets, Presentations, etc) scans and analyses everything we upload. According to Google, this is so they can “provide relevant product features, such as customized search results, tailored advertising, and spam and malware detection.”

In real talk, it’s about monetizing their platform with directed advertising after scanning our data and profiling our data subjects. That’s Google’s whole business model and they’re more or less transparent about it in their Terms of Service we all agree to when we sign up: “a worldwide license to use, host, store, reproduce, modify, create derivative works, communicate, publish, publicly perform, publicly display and distribute”. This is a license to use the data we upload and it persists even after we stop using Google’s services altogether.

Although Google’s language says some services will allow users to “access and remove” data, it’s not specific about which services these are.

Like Facebook’s licensing speak, Google’s license to use our data also applies to “those we work with”. This means 3rd parties, which could be governments, social media companies, and whoever else Google chooses to partner with. It doesn’t specify any further what this means.

Question: If it’s on Google Drive, our data is secure but is it really private?

Controlling vs. Processing

If you’re doing business outside the US and/or you require GDPR-level privacy controls, especially if you are a data controller and responsible for personal and sensitive data as well as being that data’s processor, please be aware of the Cloud-based SaaS providers’ language about this.

Google says it “processes the data on behalf of the data controller” and it is “the responsibility of the data controller to implement appropriate technical and organisational measures (or TOMs) to ensure and demonstrate that any data processing is performed in compliance with the GDPR”.

This puts all responsibility on anyone using these services as the controllers of their business data that contains personal information about other people. Here’s the real catch: under GDPR, as a data controller, we must ensure proper data security arrangements are in place to protect the personal data we process.

As a data controller, we’re obligated to ensure that we engage with processors who themselves have appropriate TOMs in place. As a processor, these processes to meet GDPR are not clear from Google’s ambiguous terms.

GDPR requires that the infrastructure storing our data has certain administrative, physical, and technical safeguards in place, which Google (and other SaaS providers) can certainly offer us, to the following points:

Network, or transmission, security is a paramount safeguard to protect against unauthorised access of protected data. This concerns all methods of transmitting data, whether it be email, Internet, or even over a private network, such as a private cloud.

Technical safeguards require access control to allow only the authorised to access electronic protected data. Access control includes using unique user IDs, an emergency access procedure, automatic log off and encryption and decryption.

Audit reports, or tracking logs, must be implemented to keep records of activity on hardware and software. This is especially useful to pinpoint the source or cause of any security violations.

Technical policies should also cover integrity controls, or measures put in place to confirm that protected data hasn’t been altered or destroyed.

Google, as an example, does a good job on these first 4, which have to do with security. However, these next two, arguably the most critical and concerned with privacy, are on us, not Google:

Physical safeguards include limited facility access and control, with authorized access in place. Policies must be in place about use and access to workstations and electronic media. This includes transferring, removing, disposing and re-using electronic media and electronic protected data.

IT disaster recovery and offsite backup are key to ensure that any electronic media errors or failures can be quickly remedied and data can be recovered accurately and intact.

The only way to solve for this with repeatable, documented consistency is to keep offline backups of all Google Drive content periodically, which also means exporting Google file types (Google Doc, Sheet, Presentations, etc.) into ones accessible outside the Google ecosystem, such as PDF, Word, Pages, Excel, and/or Keynote or Powerpoint files. And that only solves one of these challenges, leaving the “right to be forgotten” one and others in limbo as using any Cloud-based SaaS removes much of the control we have over our data.

Right to be Forgotten

Article 17 is arguably the most widely discussed component of GDPR, the “right to be forgotten”. If Google (or any Cloud-based SaaS provider) retains our information long after we’ve stopped using their service, for just one example, how can this ever be enforced without potentially creating liability for organizations that use their services?

Time will tell.

Regardless, any of the short-term solutions that we can consider at present to help us rest easy about are not yet friendly or sustainable. For the moment, there’s no answer to this paradox, which is why it’s important to be aware of it.

There are most definitely disputes on the way in the future that will help define how this problem will make the difference between being found in compliance or negligent and on the hook for 4% of your annual revenue.