This is the second in a series of articles explaining how companies should address the daunting requirements around data security and cloud services contained in the GDPR. With the May 2018 compliance deadline looming, organisations should already be on the path to compliance. With cloud services a major part of the GDPR puzzle, this series of articles is designed to provide practical guidance to help organisations along the road to compliance.
In the previous article, we looked at how organisations could address the first “audit” stage. This first step in the GDPR compliance process can be broadly summed up in the following headings:
Discover every cloud application used by employees across the business;
Know which personally identifiable information (PII) and data are being processed in the cloud by employees, and understand whether this data is defined as “sensitive” under the GDPR;
Secure data by conducting a GDPR readiness assessment, checking that you have a DPA (data protection agreement) in place with all cloud services. Set and activate policies which mandate the use of managed cloud services to process and store PII;
Coach employees in best practice to ensure staff readily adopt and use the services approved by IT, and
Use a cloud access security broker (CASB) to evaluate whether the cloud apps and services in use across the business are enterprise-ready.
With those stages of the audit complete, the organisation will be in a much better position to assess what needs to be done to achieve GDPR compliance. The next question is how organisations action that insight to improve their GDPR readiness, which brings us to stage two: rationalise.
The rationalise stage is essentially about taking the learnings from the audit stage and applying those to the cloud services in use in order to shrink the organisation’s threat landscape.
Following the audit, IT teams will have a good picture of data at rest and in-transit (and indeed where that data is going). The report from the audit will also show which cloud services are in use across the organisation, what data is in there, and then whether there is a data processing agreement (DPA) in place.
Building on this information, the rationalise stage can be defined as follows:
Find cloud services in use from the audit stage which do not have a DPA in place;
Consolidate those services, narrowing down onto a manageable number of secure cloud services which have DPAs in place;
Sanction services which do not comply with the GDPR, and strongly consider blocking the use of those which are non-compliant and show serious security deficiencies. Transition to alternatives;
Execute a data protection agreement (DPA) with all services which are – or will be – in use by employees.
Organisations will need to be able to demonstrate to regulators that they have DPAs in place with all cloud services in use by employees. Likewise, a key part of the rationalise stage is proving that data does not go to apps which do not have a DPA in place with the organisation.
IT teams can use a CASB to examine traffic flowing to and from cloud services to inspect the data and characters being transmitted. This will determine if any of the data is PII, and therefore covered under the GDPR. If so, IT teams can take action within the platform to block data and stop it being transmitted by or stored in the cloud service in question.
Similarly, if an IT team discovers traffic flowing to or from a cloud service with which the organisation does not have a DPA in place, the team can block data flow to help ensure GDPR compliance. At this stage, a modern CASB can deliver a pop-up message to nudge the employee towards a compliant solution with which the organisation has a DPA in place. Essentially, the IT team is looking for preventative control over where data travel and are stored.
Data residency is another important piece of the puzzle. CASBs can shed light on where data resides via analysis of IP addresses which would show that the user is in the UK, but that the cloud service in question is hosted in South America (for example). While there is nothing in the GDPR to say that data cannot be stored outside of Europe, the organisation must guarantee that the third party is GDPR-compliant – and of course that there is a DPA in place.
Any analysis of cloud services in use should include assessments of specific GDPR parameters. As well as DPAs and data residency, a typical GDPR readiness calculation should check whether the customer owns the data under the terms of the cloud service, whether audit logs are recorded on data access, and the time taken by the “data processor” (the cloud service) to remove data from that service.
The GDPR readiness calculation should also assess whether data is encrypted at rest and/or in transit, whether the service provides measures for external authentication such as single sign-on (SSO) and whether the service has compliance certifications.
Some of these criteria are mandatory under the GDPR, others are recommended. But taken together, the answers to these questions will guide an organisation’s decision to rationalise on certain cloud services – jettisoning any services which don’t meet these standards.
The findings of the September 2017 Netskope Cloud Report™ on enterprise cloud service usage and trends emphasise the importance of the rationalise stage on the journey towards GDPR compliance. Investigating GDPR readiness among enterprise cloud services, the report found that almost three-quarters of cloud services still lack key capabilities to ensure compliance.
With the average number of cloud services standing at 1,022 per enterprise, this shows that organisations have to keep a careful eye on data flowing in and out of these services. To further muddy the waters, many cloud storage and collaboration services connect to other cloud services (for example, cloud storage connecting to Salesforce or DocuSign). A comprehensive cloud security programme should take into account what controls to place in cloud service-to-cloud service communications and processing, including making sure DPAs are in place with these “secondary” services.
It’s a difficult landscape, and the scale of the challenge clearly demonstrates why the rationalise stage is so important to GDPR compliance. Organisations must restrict services with no DPA, identify services to sanction and place security controls on, and finally execute DPAs.
Then once the rationalise stage is complete, it’s time to approach the third stage: enforce. We’ll cover that next time.
