GDPR and the cloud – an introduction

This page introduces some of the General Data Protection Regulation’s (GDPR) most important elements with a special focus on cloud services. The GDPR is an EU regulation that started applying on 25 May 2018.

As a compliance-focused cloud infrastructure provider, we know some organisations may be overwhelmed by what it takes to be compliant with the GDPR in the cloud.

In this article we introduce some core aspects of the GDPR, while taking things one step further. This article goes deeper than a surface-level understanding, aiming to be practically useful.

In particular, each part of this article has a section dedicated to considerations especially relevant to GDPR compliance when an organisation wants to use the cloud.

We hope you find the article useful.

While this article refers to the EU, the GDPR applies throughout the EEA, which includes the EU as well as Iceland, Lichtenstein and Norway.

Main goals of the GDPR

The GDPR has two main goals:

1. Protecting the fundamental rights and freedoms of natural persons and in particular their right to the protection of personal data.
2. Facilitating the free flow of personal data across the EU, by applying consistently applying one set of rules throughout the EU.

Fundamental rights are particularly important in the EU legal order.

The free flow of personal data can be seen as part of the EU’s goals for the internal market, removing barriers to economic activity.

In case of conflict between EU law (such as the GDPR) and the laws or constitution of an EU member state, EU law takes precedence.

Good to know when using cloud services

As technology evolves, including cloud services, the GDPR’s main goals remain as important as ever.

We believe a high level of protection for fundamental rights promotes trust in modern technologies, and is vital to retain our humanity in the digital age.

Modern cloud services work across borders. An organisation in France can easily use a cloud service delivered out of Sweden. It is therefore crucial that the EU’s high level of protection for fundamental rights is applied homogenously throughout the EU. The GDPR aims to achieve this. If some countries had less stringent rules, or enforced compliance with the GDPR less strictly, it would undermine the high level of protection of fundamental rights.

The same can be said for transferring personal data outside the EU/EEA. If organisations in the EU could avoid their responsibilities by transferring personal data to cloud servers in third countries, it would undermine our fundamental rights.

For some time, there has been a discussion about whether our rights in the cloud are already being undermined to some extent. Here it can be noted that dominant US cloud service providers have established themselves in Ireland, perhaps partly due to favourable taxes, perhaps partly due to a perceived lack of appetite for action at the Irish supervisory authority responsible for enforcing the GDPR.

Key definitions

All the GDPR’s definitions are available in full in Article 4. To fully understand them properly, they should be read together with their associated recitals in the GDPR as well as case law from the Court of Justice of the European Union (CJEU).

Here is a condensed and simplified summary of some key terms that are relevant for most organisations:

1. Personal data. This is any information that directly or indirectly relates to an identified or identifiable person who is alive. The definition of personal data is interpreted broadly. Note that in order to be personal data, it is sufficient for information to relate to an identifiable person. This means an organisation could be processing information about people without knowing their specific identities (in the sense of their names, etc.), and it would still count as processing of personal data if the organisation or someone else could lawfully piece that information together with other information to identify those people.
2. Data subject. When personal data relate to a natural person who is alive, the GDPR defines such a person as a ”data subject”. In this article we will avoid that phrase, instead using more familiar words like persons or people.
3. Processing. Virtually any earthly activity performed on personal data counts as processing. Collection, retrieval, adaptation or alteration, erasure, making personal data available – even entirely passive storage – are all examples of processing. Processing can be performed with automated means, such as with a computer. Non-automated processing of personal data, such as with pen and paper, is also covered by the GDPR if the personal data is part of a filing system or intended to be part of a filing system.
4. Controller. An organisation is a controller of a processing activity if the organisation in practice determines the purposes and means – meaning why and how – the personal data is processed. The EU supervisory authorities consider that some more practical aspects of the how (called “non-essential means”), such as which specific hardware and software to use for the processing, can be delegated for processors to decide.
5. Processor. An organisation is a processor when it processes personal data on behalf of a controller. A processor only processes personal data to achieve the controller’s purposes for the processing, according to the controller’s instructions. A processor can make some decisions as to practical aspects of how the data is processed (“non-essential means”), such as which specific hardware and software to use for the processing. However, a processor makes no decisions of its own as to the purposes why personal data is processed.

It is also good to know that the GDPR does not apply to a person who processes personal data in the course of a purely personal or household activity.

Good to know when using cloud services

An organisation using a cloud service is typically seen as a controller under the GDPR, while the cloud service provider is seen as a processor. This is often correct, although things can be more nuanced.

The role of a controller or processor applies only in relation to processing activities. When we talk about a controller organisation, we are therefore talking about an organisation which is the controller of specific processing of personal data. That same organisation can also or alternatively be a processor, if it performs processing activities on behalf of someone else. The role of controller or processor is always tied to one or more identifiable processing activities.

A cloud service provider, especially a provider of a SaaS solution, is often times a processor of personal data on behalf of its customers, but also a controller to some extent.

A cloud service provider becomes a controller of processing of personal data when it uses personal data for its own purposes. These purposes may be legitimate, such as when a SaaS provider logs a limited amount of specific data necessary to keep the cloud service secure.

In other cases things can – at least in our view – be more or less questionable. An example would be if a cloud service provider allows itself to use wide-ranging types of personal data for ambiguous purposes such as to improve the service (without providing further detail). Another could be if the cloud service provider calculates compensation to salespeople based on how the customer’s staff uses the cloud service.

When a cloud service provider uses personal data as a controller, Article 12 GDPR requires the cloud service provider to inform the persons whose personal data is processed. This is often called a privacy notice, or less accurately a privacy policy.

Organisations considering using a cloud service should therefore carefully review if and how the cloud service provider uses personal data as a controller (meaning for its own purposes), as well as if and how the cloud service provider informs people about this in line with the GDPR’s requirements. This can then be part of the organisation’s assessment of whether the cloud service provider’s use of data is acceptable, and if the cloud service provider is fulfilling its responsibilities as a controller.

On the other hand, when the cloud service provider acts as a processor of personal data on behalf of its customers, that processing should be outlined in a data processing agreement between the cloud service provider and each customer.

Territorial scope of the GDPR

Article 3 GDPR sets out its territorial scope.

Organisations are bound by the GDPR under the following circumstances:

1. Controllers and processors established in the EU where their activities involve processing of personal data, regardless of whether the processing takes place in the EU or not.
2. Controllers and processors not established in the EU who process personal data relating to persons in the EU, where the processing activities relate to:
   • the offering of goods or services to persons in the EU, regardless of whether payment is required, or
   • the monitoring of the behaviour of persons in the EU, as far as their behaviour takes place within the EU.

Good to know when using cloud services

Organisations in the EU should especially recall the first point: their EU activities involving processing of personal data are in scope of the GDPR, even if the processing itself takes place outside the EU.

For example, an organisation’s staff in the EU might rely on a cloud service provider with servers in Switzerland (a non-EU/EEA country). In such a case, the GDPR still applies to the organisation for the processing that takes place on the servers in Switzerland.

Some cloud service providers give themselves great leeway to transfer personal data to virtually any third country at any given time. This risks taking away the customer organisation’s control over where personal data travels and how well it is protected. It can be difficult or impossible for a customer organisation to assess each third country before such transfers takes place, even though the organisation has formally approved those transfers in advance.

The fundamental right to data protection

It’s right there in the name – the General Data Protection Regulation. So what does data protection actually mean?

First, the data covered by the GDPR is only personal data. Simply put, this is any information that relates, directly or indirectly, to an identified or identifiable person who is alive.

Second, while it’s easy to think protection simply means security, this is far from the whole picture. Under EU law, protection of personal data means much more than just information security in the traditional sense.

Article 8 of the Charter of Fundamental Rights of the European Union enshrines the right to protection of personal data. That article says:

It is useful to examine the second of these points in particular. Here we learn that personal data must be:

1. Processed fairly.
2. For specified purposes.
3. On a legitimate basis laid down by law.

We also learn that everyone has a fundamental right to:

1. Access the data which has been collected about them.
2. The right to have personal data about them rectified (corrected).

Because EU Charter fundamental rights are part of EU primary law, the GDPR must be interpreted in line with those rights.

Fundamental rights have a strong position in the EU legal order, but they are not absolute. Limitations can be placed on fundamental rights, if the limitations are provided for by law and satisfy certain strict requirements.

The Court of Justice of the European Union (CJEU) can be seen as a supreme court when it comes to EU law. The CJEU ultimately interprets the scope and limitations of EU fundamental rights and the GDPR. All national courts in EU member states are bound by the CJEU’s interpretations and judgments.

Good to know when using cloud services

Using cloud services can sometimes appear as something purely technical, with no effect on people’s fundamental rights compared to using on-premises software. However, when organisations use cloud services to process personal data, respecting fundamental rights can be key to compliance.

For example, the famous Schrems II case concerning third country transfers under the GDPR, raised awareness of the problems inherent in cloud services provided by US based companies. The case did not ultimately hinge on an interpretation of the GDPR, but on an interpretation of the EU Charter. Specifically, the CJEU examined if US surveillance law fulfilled the EU Charter’s requirements for the fundamental rights to private life, protection of personal data and an effective remedy before a tribunal. Such an assessment is perhaps not the first thing that comes to mind for organisations considering going into the cloud!

The GDPR’s data protection principles

The GDPR takes the fundamental right to protection of personal data, adds additional rights for persons and obligations for organisations, and makes these concrete across 99 articles and 173 recitals.

As luck would have it, the GDPR’s main principles are all gathered in one article – Article 5 GDPR.

This article lists six principles for processing personal data, and a seventh principle about being able to demonstrate compliance with the other six.

Here is a condensed and simplified summary of what the GDPR’s principles for data protection mean for controller organisations.

1. Lawfulness, fairness and transparency. Organisations must have a lawful basis to process personal data, they must use the data fairly, and provide clear and concise information to individuals about the processing.
2. Purpose limitation. Organisations must only collect personal data for explicit, legitimate purposes that they have specified, and must not further use the data in a manner incompatible with those original purposes.
3. Data minimisation. Organisations must only collect and use the types and amounts of personal data actually necessary to achieve the organisation’s stated purposes for the processing – not more.
4. Accuracy. Organisations must take every reasonable step to ensure that they will, without delay, erase or rectify inaccurate personal data.
5. Storage limitation. Organisations must keep personal data only for as long as is necessary to achieve their stated purposes of the processing – no longer.
6. Integrity and confidentiality. Organisations must ensure appropriate security of personal data, including protection against unauthorised or unlawful use of the personal data, and against its accidental loss, destruction or damage.
7. Accountability. Organisations are responsible for and must be able to demonstrate compliance with the preceding six principles.

As evident, mainly one principle (number six) is concerned with traditional information security.

To be compliant with the GDPR’s data protection principles a controller organisation must also, for example, define purposes for its processing, ensure that it only collects and uses personal data necessary to achieve those purposes and only for the duration necessary, make accurate legal assessments of the lawfulness of the processing, and provide clear and concise information to individuals about the processing.

It is also appropriate to mention what’s usually called the principles of data protection by design and by default under Article 25 GDPR. The principle of data protection by design means that when a controller uses e.g. a cloud solution, that use shall accommodate the aforementioned 6+1 data protection principles. Data protection by default requires implementation of defaults (such as default settings in a SaaS solution) that respect the principles of data minimisation, storage limitation and confidentiality.

Almost every GDPR obligation an organisation faces can in some shape or form be tied to one of the above-mentioned GDPR principles. Referring back to these principles can often be of great help in an organisation’s GDPR compliance work.

Good to know when using cloud services

When asked questions related to the GDPR, some cloud service providers are happy to emphasise their traditional information security work. Such work might give effective protection against intrusions (even though this too has sometimes been called into question), without demonstrating an understanding of the GDPR’s other requirements.

As evident from the data protection principles, the GDPR is about more than just security. When using a cloud service, an organisation has to ensure compliance with all the GDPR’s principles. For example, does the cloud service provider use personal data for its own dubious purposes? Does the cloud service provider give itself permission to transfer personal data from the EU to third country authorities in secret without a valid legal basis, and in violation of its article 32.4 obligations?

It is also relevant to examine how a cloud service has implemented the principles of data protection by design and by default, especially if it is a SaaS solution. For example, does the solution make privacy-sensitive information about users available to administrators, even though this isn’t necessary for administrative or security purposes? Is the cloud service designed to accommodate the need to be able to export, rectify and erase personal data in a practical manner, without making surrounding information useless? These responsibilities fall on the controller, even when using a SaaS solution designed by someone else. Controller organisations should therefore ensure their prospective processors have built their solutions in a way that allows the controller to comply with its GDPR obligations.

Here, the EDPB’s Guidelines 4/2019 on Article 25 Data Protection by Design and by Default may be of help.

Legal basis for processing

A controller organisation needs to be able to rely on one or more valid legal bases under the GDPR for each of its processing activities.

There are six legal bases, which are set out in Article 6 GDPR.

For most organisations, we believe the following four legal bases are likely to be the most common. They are recounted in somewhat simplified form.

1. Compliance with a legal obligation, under Article 6(1)(c) GDPR. Used if it is necessary to process certain personal data in order to comply with a legal obligation laid down by EU law or the law of an EU/EEA member state. For example, an organisation needs to process personal data in order to fulfil its legal obligation to report employee salaries to the tax authorities.
2. Performance of a contract with the person whose personal data is processed, under Article 6(1)(b) GDPR. Used if it is necessary to process certain personal data to perform a contract with the person whose data is processed. For example, an organisation must pay out salaries to fulfil its employment contracts, and it may be necessary to collect the employees’ bank account numbers in order to do this.
3. Legitimate interests pursued by the business or by a third party, under Article 6(1)(f) GDPR. Used if it is necessary to process certain personal data for the purposes of a legitimate interest pursued by the organisation or by a third party, and this interest weighs heavier than the interest of the persons concerned to not have their personal data processed. Such an assessment should especially take into account the persons’ reasonable expectations with regard to why and how their personal data would be processed. For example, an organisation and its employees have a legitimate interest in the company storing emergency contact information for its employees. The resulting privacy intrusion for those contact persons should be relatively small. It should also be within the reasonable expectations of employees and the contact persons.
4. Consent, under Article 6(1)(a) GDPR. Used if a person provides freely given consent for processing of their personal data for one or more purposes. An organisation must satisfy numerous requirements to receive valid consent under the GDPR, including that the consent is informed, genuinely freely given, and can be withdrawn at any time. An example of where consent may be appropriate to use, is when a person signs up to receive a marketing newsletter by email.

When determining which of these legal bases may be used, we believe it may be appropriate to assess them in the order given above.

Public authorities and other organisations performing tasks in the public interest, or in the exercise of official authority, have another legal basis to rely on when performing processing necessary for those tasks. This legal basis is found in Article 6(1)(e) GDPR, and would fit between the second and third points above when assessing different legal bases. When public authorities perform their tasks, they must rely on this legal basis instead of legitimate interest, because public authorities cannot rely on legitimate interest in the performance of their tasks.

Finally, there is a legal basis for processing personal data necessary to protect the vital interests of a person. The personal data being processed could relate to the person whose vital interests are at stake, or to someone else. In either case, the processing must be necessary to protect an interest which is essential for a person’s life. Organisations must only use this legal basis if the processing cannot be manifestly based on another legal basis. This legal basis is found in Article 6(1)(d) GDPR, but is only rarely relevant.

Good to know when using cloud services

A SaaS provider could supply its own assessments as to which legal basis their customers should rely on when using the SaaS provider’s cloud service. Such assessments can be a helpful starting point for a controller organisation’s own analysis.

However, the controller organisation is always responsible for making its own assessment of which legal basis to rely on for each processing activity. This is true even when the processing is performed using a cloud service. In some cases, an organisation might conclude that no legal basis fits a certain processing activity, meaning that processing activity is therefore not possible. Even if the organisation can identify a valid legal basis, it should be recalled that all the other obligations under the GDPR still apply, such as the data protection principles.

Organisations should be especially careful when a potential cloud service provider wants to collect personal data originating from its customers, and use that data for the cloud service provider’s own purposes. In such a case the customer organisation, acting as a controller, would effectively be disclosing personal data to the cloud service provider, which in this case is acting as a separate controller. The customer organisation’s disclosure is itself a processing activity. This means the customer organisation must assess that it has a valid legal basis for the disclosure. If the cloud service provider intends to use the personal data it receives for vague or questionable purposes, it may be difficult or impossible for the customer organisation to establish that it has such a valid legal basis for the disclosure.

Special categories and other sensitive personal data

Special categories of personal data

As a starting point, the GDPR prohibits processing of certain types of especially sensitive personal data. These are called special categories of personal data, and are personal data concerning a person’s:

• health
• genetics
• sex life or sexual orientation
• racial or ethnic origin
• political opinions, religious or philosophical beliefs
• trade union membership
• biometric data for the purpose of uniquely identifying a person.

There are exceptions to the GDPR’s default prohibition. Being able to use such an exception allows a controller organisation to lawfully use special categories of personal data.

The prohibition appears in Article 9(1). The exceptions are listed in full in Article 9(2).

In simplified terms, these exceptions can be used when:

• the data subject has given explicit consent to the envisaged processing, and EU law or the law of an EU member state does not prevent consent from being given for such processing,
• the processing is necessary for the controller or the data subject to carry out their obligations or use their rights in the context of employment and social security and social protection law, or a collective agreement,
• processing is necessary to protect the vital interests of the data subject or of another natural person where the data subject is physically or legally incapable of giving consent,
• processing is carried out by a foundation, association or other not-for-profit body with a political, philosophical, religious or trade union aim. Furthermore, the processing must solely relate to the members or former members of the body or to persons who have regular contact with it in connection with its purposes. In addition, the personal data cannot be disclosed outside that body without the consent of the data subjects.
• processing relates to personal data which are manifestly made public by the data subject,
• processing is necessary for the establishment, exercise or defence of legal claims, or whenever courts act in their judicial capacity,
• processing is necessary for reasons of substantial public interest, on the basis of EU law or the law of an EU member state,
• processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of an employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services,
• processing is necessary for reasons of public interest in the area of public health, such as protecting against serious cross-border threats to health or ensuring high standards of quality and safety of health care and of medicinal products or medical devices,
• processing is necessary for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes.

The exceptions listed here are provided in simplified form. To fully understand each exception, it is necessary to read the entirety of Article 9 GDPR. Also note that the GDPR allows EU member states to further limit use of genetic data, biometric data or data concerning health.

An organisation that wants to process special categories of personal data must have both a legal basis under Article 6 GDPR and an applicable exception under Article 9(2) GDPR.

Personal data relating to criminal convictions and offences

Processing of personal data relating to criminal convictions and offences is also strictly regulated under the GDPR. Like with special categories of personal data, identifying a legal basis under Article 6 GDPR is just the start.

In addition, under Article 10 GDPR the processing of personal data relating to criminal convictions and offences “shall be carried out only under the control of official authority or when the processing is authorised by Union or Member State law providing for appropriate safeguards for the rights and freedoms of data subjects.“

For most organisations, this means being able to point to a specific authorisation under EU law or the law of an EU member state, which allows them to process such personal data. For example, Swedish law authorises specific types of employers to use criminal convictions and offences data before hiring a person. The Swedish supervisory authority has also issued rules (DIFS 2018:2 Föreskrifter om behandling av personuppgifter som rör lagöverträdelser) allowing for criminal convictions and offences data to be processed in certain contexts.

Good to know when using cloud services

The GDPR regulates processing of special categories of personal data primarily by requiring that one of a number of particular, specified justifications applies. Meanwhile, processing of criminal convictions and offences data requires most organisations to have additional authorisation in EU law or the law of an EU member state.

The GDPR regulates the processing of special categories of personal data primarily by requiring that one of a number of particular, specified justifications applies. At the same time, for most organisations, the processing of personal data relating to criminal convictions and offences requires that the organisation can point to some part of EU law or the national law of an EU member state which authorises that processing.

It is easy to see that if special categories or criminal convictions and offences data were to leak or be used inappropriately, this could potentially have serious consequences for an affected individual.

Here we can recall the GDPR’s rules related to the security of the processing. These rules require organisations to protect personal data with a level of security appropriate to the risk. Organisations must take into account various aspects like the nature of the processing and the risks to individuals. The more sensitive the data, the higher the level of security required.

This naturally applies to special categories or criminal convictions and offences data, but equally well to other types of sensitive personal data. For example, information about a person’s economic situation, or a person’s location over time, can be highly sensitive even if it does not qualify as special categories or criminal convictions and offences data. Personal data must be adequately protected regardless of whether it has special status under Articles 9 or 10 of the GDPR.

The sensitivity of personal data and processing are relevant in the context of non-security related GDPR violations as well. For example, one company received a €290 million fine after transferring more or less sensitive personal data to the United States without a valid transfer mechanism. This was despite not necessarily having violated the GDPR’s rules regarding appropriate security for the personal data.

Thus, it is vital for organisations to ensure they handle sensitive personal data correctly under the GDPR, whether it is from a security point of view or other compliance aspects that need to be ensured. This includes when an organisation uses cloud services where a range of aspects could become relevant, from security, to protecting against third country access, to the data protection principles.

Individual rights

The GDPR gives persons a number of rights which entail obligations for controllers. These include:

1. Right to information. Controllers have to provide certain information to the persons whose data are processed, such as information about the processing’s purposes, legal basis and whether there are third country transfers. Article 12 requires controllers to provide this information “in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child“. Article 13 lists the information to be provided to a person when personal data are collected from them. Article 14 lists the information to be provided to a person when their personal data are obtained from another source.
2. Right of access. Controllers have to provide access to a copy of personal data relating to a person requesting this. This is often called a data subject access request (DSAR). Article 15 explains this right.
3. Right to rectification. Controllers have to rectify (correct) inaccurate personal data relating to a person requesting this, without undue delay. Article 16 explains this right. Controllers also have a separate responsibility under Article 5(1)(d) to take every reasonable step to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay.
4. Right to erasure, or the “right to be forgotten“. Controllers have to erase certain personal data relating to a person requesting this, without undue delay. Article 17 explains this right.
5. Right to restriction. If one of several conditions apply, controllers have to restrict how they process personal data relating to a person requesting this. For example, if a controller organisation no longer needs certain personal data about a person and so would therefore normally delete those data, the person can ask the controller to keep the data anyway if this is necessary for the person to establish, exercise or defend a legal claim. Article 18 explains this right.
6. Right to data portability. If a person provides personal data relating to themselves to a controller based on consent or on a contract, and the controller processes those data by automated means, the controller has to provide the person with the personal data in a structured, commonly used and machine-readable format, and the person has the right to transmit those data to another controller without hindrance from the original controller. Article 20 explains this right.
7. Right to object. If a controller organisation processes personal data about a person because it is necessary to perform a task in the public interest, or to exercise official authority, or for the purposes of a legitimate interest, that person can object to the processing on grounds relating to the person’s particular situation. The controller shall no longer process the personal data unless it demonstrates compelling legitimate grounds for the processing which override the interests, rights and freedoms of the person, or for the establishment, exercise or defence of legal claims. If the processing was for direct marketing purposes, the controller must stop the processing regardless. Article 21 explains this right.

It is important to understand that these rights are not absolute. In fact, the GDPR restricts them in several important ways.

For example, a person’s right of access to a copy of their personal data only applies to the extent it does not adversely affect the rights and freedoms of others. This might mean that an organisation can provide a copy of surveillance camera footage to a person requesting it, but only after the footage has been partially blocked out to only show the requesting person and not others. Similarly, a person asking for personal data about their presence in a log may not receive the entire log, but rather the parts where the requesting person appears in it. If the person asks if their log entries have been previously reviewed and by whom, the organisation might respond with information about when its staff accessed the relevant parts of the log (if this information too was logged), but probably not the identities of the staff members who reviewed the log (cf. CJEU case C-579/21 Pankki S, p. 83).

Another example of a restricted right is the often misunderstood right to erasure, sometimes called the right to be forgotten. In most cases this right applies when an organisation would have had to erase personal data anyway. This is because by default, the GDPR requires an organisation to stop processing personal data if it no longer needs that data. If, on the other hand, the organisation has an appropriate and lawful reason to keep certain personal data, the right to erasure will often not take precedence.

More information about how each right is restricted is available in the full article text of each right, linked above.

Good to know when using cloud services

A controller organisation is responsible for satisfying people’s rights under the GDPR, even when the organisation uses a cloud service provider which acts as a processor. Organisations should therefore examine cloud solutions considered for use, especially SaaS solutions, to clarify how the organisation would fulfil e.g. a request for access, rectification, erasure, or portability. It is wise to not assume all IT solutions support fulfilling these GDPR rights in a practical manner.

For example, does an evaluated SaaS solution make it possible to rectify and erase relevant personal data? Can this be done from a user interface or does it require asking the cloud service provider to manually edit a database file? If there is an export tool, does it actually provide a copy of all relevant personal data in an accessible format? If not, how much additional manual work can be expected to find and export the remaining data?

Different cloud solutions may to different extents support an organisation’s obligation to fulfil these GDPR rights.

Security

Article 32(1) of the GDPR requires organisations to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. They shall do this by taking into account:

• the state of the art,
• the costs of implementation,
• the nature, scope, context and purposes of processing, and
• the risk, of varying likelihood and severity, for the rights and freedoms of natural persons.

In assessing what is an appropriate level of security, organisations shall in particular take into account the risk of accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data being processed.

Article 32(1) mentions a number of technical and organisational measures to be implemented as appropriate:

• the pseudonymisation and encryption of personal data,
• the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services,
• the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident, and
• a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

This view on risk, and the toolbox of measures, will to some extent be familiar territory to organisations already working systematically with information security. What may be unfamiliar at first, is that the GDPR requires organisations to look beyond their self-interest.

In a traditional information security management system, an organisation sets its own priorities and goals. Unless these priorities and goals are reviewed and clarified, they might not take into account the risks to the rights and freedoms of persons as required under the GDPR.

It can therefore be especially useful for an organisation to involve people who can see things from the point of view of the people whose personal data is processed. This enables considering the range of risks those people could be subject to, and the consequences they could suffer, from material to non-material, e.g. purely emotional.

The GDPR’s risk-based approach

Depending on their nature, personal data breaches can cause serious privacy violations and have wide-ranging consequences for affected persons. Security gets plenty of attention in the context of personal data, and for good reason. However, not all personal data breaches are the same.

Article 32(1) GDPR requires a level of security appropriate to the risk. As previously mentioned, the risks to be taken into account may be more wide-ranging than some organisations are used to. That does not, however, mean that the risks are always the same or always as serious.

Different levels of security risks will therefore be met with different levels of security measures. These are often called technical and organisational measures, or TOMs. When implementing measures, the GDPR says organisations shall take into account a number of factors, including the state of the art and the costs of implementation. In other words, Article 32(1) GDPR does not prescribe perfect security – such a thing is generally considered impossible.

Perhaps surprising to some, this also means an organisation might suffer a personal data breach without this being a GDPR violation. The question is rather whether the organisation had implemented a level of security measures appropriate to the risk. Of course, an organisation cannot arbitrarily decide that an appropriate level of security happens to be miniscule. The more sensitive the data and the nature of the processing, and the more likely and severe the risks are, the higher the security level needs to be. But a requirement for perfection there is not.

This level of relative freedom in assessing risks and corresponding measures, as expressed in the so-called risk-based approach, applies to Article 32(1) GDPR. In other areas of the GDPR the margins of interpretation are tighter. In some cases, the GDPR itself has already identified a risk and the need for measures to ensure it does not materialise. Further below we will examine one such example in Article 32(4) GDPR.

Good to know when using cloud services

ISO 27001 certification

Organisations considering use of cloud services often rely on a cloud provider’s ISO 27001 certification as an element in demonstrating compliance with the GDPR’s security requirements. A few things should be kept in mind here.

First, when an organisation uses a SaaS cloud service, this often involves 2–3 levels of actors: the immediate SaaS provider, the SaaS provider’s infrastructure (IaaS) provider, and the infrastructure provider’s data center provider. Just because one of these actors has an ISO 27001 certification, this does not mean the other actors are also certified. Organisations should assess at which of these levels of provider a certification is necessary considering the type of SaaS service and processing.

Second, organisations should examine the scope of the relevant provider’s ISO 27001 certification, to verify that it includes provision of the relevant service. It may be of limited value to discover that a provider’s ISO 27001 certification only covers the activities of its HR department.

Third, it can be relevant to review which version of ISO 27001 a provider follows or is certified against. For example, the ISO 27001:2022 version of the standard adds privacy and business continuity controls. Is the provider using that version, or still relying on an older version?

Fourth, while an ISO 27001 certified provider has a systematic approach to information security, this does not necessarily guarantee that the provider’s risk assessment is aligned with its customers’. Not least when it comes to especially sensitive processing, it can be appropriate to discuss with the provider the types of security risks it has identified as relevant, and the types of security measures (called controls in ISO 27001 parlance) it has implemented to handle those risks.

Protection against third country extraterritorial laws

Another security aspect of the GDPR, which is especially relevant to cloud services, concerns the GDPR’s rules to prevent disclosures of personal data to third country authorities.

While the risk-based approach of Article 32(1) GDPR requires organisations themselves to assess risks and if measures are needed, Article 32(4) in contrast makes such an assessment for them. Article 32(4) requires organisations to take steps to ensure their staff do not transfer personal data to third country authorities.

Specifically, Article 32(4) GDPR says: “The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by Union or Member State law.“ (Cleura’s emphasis)

For example, this allows a cloud service provider’s staff to comply with a legally valid demand for personal data from an EU member state’s police authority. However, Article 32(4)’s requirement means that the cloud service provider must take steps to ensure that its staff do not make disclosures under the legal regimes of third countries. Article 29 GDPR expresses a requirement with the same aim.

This question is highly relevant to cloud services from US providers, as the United States is a third country. US cloud service providers have repeatedly explained their rigorous procedures for complying with demands for data from US authorities under US law. In other words, US cloud providers ensure the opposite of the GDPR’s requirement that they take steps to ensure that such disclosures do not happen. We argue that this prevents such providers from being used as processors under Article 28(1) GDPR. This is because US cloud service providers plainly do not provide controllers sufficient guarantees to meet the GDPR’s requirements, including the ones that follow from Article 28.3 a, 29 and 32(4), and they do not ensure the protection of data subjects’ rights.

Cleura has an in-depth report on the GDPR’s requirements to protect personal data from disclosures to third country authorities. The report also explains why these GDPR requirements apply regardless of the EU-US Data Privacy Framework (DPF) and the associated adequacy decision. Read more in the report What your organisation needs to know about the third adequacy decision.

Personal data breaches

The GDPR defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.

This means a personal data breach has to involve a security breach of some form, involving personal data. A stolen laptop containing personal data, or an intrusion by hackers copying a database of personal data, are two examples of personal data breaches.

If there is a personal data breach, Article 33(5) GDPR requires controllers to document the facts relating to the breach, its effects and the remedial action taken.

In addition, some personal data breaches have to be notified to the supervisory authority, and a subset of these have to be communicated to affected persons. These obligations apply depending on the severity of the risks for persons affected by the breach.

If a personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons, controllers do not have to notify the breach to the supervisory authority. Other breaches have to be notified to the supervisory authority without undue delay and, where feasible, not later than 72 hours after the controller becomes aware of the breach.

If a personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, controllers have to communicate the breach to affected persons without undue delay. Other breaches do not have to be communicated to affected persons.

Good to know when using cloud services

When an organisation relies on a cloud service provider, it can be relevant to review the procedures in place for handling personal data breaches.

For example, does the organisation know how the cloud service provider would inform the organisation of a personal data breach? Does the organisation monitor that channel appropriately? Would the information be sent from a no-reply email address, and if so, is there another channel agreed where the organisation can ask follow-up questions and maintain a dialogue?

Other preparations can also be of help, regardless of whether an organisation uses cloud services. Is the organisation capable of assessing, within the required time frames, whether a personal data breach must be notified to the supervisory authority and communicated to affected persons, respectively? Is it aware of how to notify the supervisory authority, and is there a plan for how to communicate a breach to affected persons?

Preparations like these can avert delays and avoid disarray when time is of the essence and composure is at a premium.

Record of Processing Activities (ROPA)

Organisations employing 250 or more persons are obliged to maintain a record of processing activities. The register has to include certain mandatory information regarding the processing activities the organisation performs. This is often referred to as a ROPA, or an Article 30 register.

For organisations employing fewer than 250 persons, the record obligation only covers:

• non-occasional processing of personal data,
• processing likely to result in a risk to the rights and freedoms of persons whose data is processed, and
• processing of certain sensitive data covered by articles 9 and 10 of the GDPR.

A ROPA describes the types of processing activities an organisation performs as a controller. It is not a record where notes are made each time personal data is processed. The ROPA enables an organisation to maintain an overview of how it uses personal data, which is very helpful in its other GDPR compliance efforts.

For processing activities an organisation performs as a controller, the ROPA shall include:

a. the name and contact details of the controller and, where applicable, the joint controller, the controller’s representative and the data protection officer;
b. the purposes of the processing;
c. a description of the categories of data subjects and of the categories of personal data;
d. the categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries or international organisations;
e. where applicable, transfers of personal data to a third country or an international organisation, including the identification of that third country or international organisation and, in the case of transfers referred to in the second subparagraph of Article 49(1), the documentation of suitable safeguards;
f. where possible, the envisaged time limits for erasure of the different categories of data;
g. where possible, a general description of the technical and organisational security measures referred to in Article 32(1).

If an organisation is a processor of personal data on behalf of a controller, it needs to maintain a ROPA for those processing activities as well. That ROPA shall include:

a. the name and contact details of the processor or processors and of each controller on behalf of which the processor is acting, and, where applicable, of the controller’s or the processor’s representative, and the data protection officer;
b. the categories of processing carried out on behalf of each controller;
c. where applicable, transfers of personal data to a third country or an international organisation, including the identification of that third country or international organisation and, in the case of transfers referred to in the second subparagraph of Article 49(1), the documentation of suitable safeguards;
d. where possible, a general description of the technical and organisational security measures referred to in Article 32(1).

Good to know when using cloud services

A situation where it is useful to have an up-to-date ROPA is when a controller organisation intends to use a cloud service provider as a processor. This requires the parties to enter into a data processing agreement.

Under Article 28(3) GDPR, a data processing agreement must include certain information. A controller which maintains a ROPA will already have much of this information readily available, making it much smoother to enter into the data processing agreement.

Enforcement

Each EU country has a supervisory authority responsible for monitoring and enforcing how organisations comply with the GDPR. For example, in Sweden, this is the Swedish Authority for Privacy Protection, called Integritetsskyddsmyndigheten (IMY) in Swedish.

Under Article 58 GDPR, supervisory authorities have a number of investigative powers. These powers include ordering organisations to provide information, carrying out audits, as well as accessing premises and equipment.

A supervisory authority’s corrective powers include, amongst others:

• ordering an organisation to pause or stop specific processing of personal data,
• ordering an organisation to change the way it processes personal data,
• ordering an organisation to communicate a personal data breach,
• ordering the suspension of transfers to a third country,
• ordering an organisation to erase personal data,
• imposing an administrative fine,
• issuing a reprimand.

The power to impose administrative fines has received plenty of attention because of the maximum level of these fines. Infringing some provisions of the GDPR can lead to fines of up to 20 000 000 EUR, or in the case of an undertaking (e.g. a company), up to 4% of the total worldwide annual turnover of the preceding financial year, whichever is higher. For other provisions the corresponding limits are 10 000 000 EUR or up to 2%. Note that for public authorities, the maximum can be significantly lower. The website GDPR Enforcement Tracker publishes a database of fines which can be ordered by amount and filtered by country. The largest fine it has on file concerns third country transfers.

While the maximum level of fine can appear large, the GDPR requires that each fine is effective, proportionate and dissuasive. Fines have to be large enough to leave a dent, and not to be so low as to make infringement preferable to compliance. However, the requirement for proportionality also means that a fine shouldn’t be larger than necessary to achieve the goals of the fine. The EU supervisory authorities say they consider both the severity of an infringement and the size of an undertaking to verify the proportionality of a fine’s amount. A company with a high turnover should therefore typically receive a larger fine than a company with a small turnover, if both companies have infringed the GDPR in the same way and with the same severity.

When a supervisory authority imposes an administrative fine or other corrective action, the targeted organisation can file an appeal to court. A supervisory authority’s powers are thus not absolute. If challenged, it is ultimately the courts that decide on the validity and size of imposed fines.

Good to know when using cloud services

The European Data Protection Board (EDPB) not only contributes to consistent enforcement of the GDPR, it also provides guidance and recommendations. The EDPB comprises:

• the supervisory authorities which enforce the GDPR in each EU member state, and
• the European Data Protection Supervisor (EDPS), which is the supervisory authority enforcing data protection law for the EU’s own institutions, such as the European Commission.

EDPB guidance which can be particularly helpful in relation to cloud services includes:

• Guidelines 07/2020 on the concepts of controller and processor
• Guidelines 4/2019 on Article 25 Data Protection by Design and by Default
• Guidelines 9/2022 on personal data breach notification under GDPR and Guidelines 01/2021 on Examples regarding Personal Data Breach Notification

The websites of national supervisory authorities may have additional guidance relevant to the cloud.

Complaints to the supervisory authority

Under Article 77 GDPR, a person who believes that an organisation is processing their personal data in violation of the GDPR can lodge a compliant with the supervisory authority.

When a supervisory authority investigates a complaint, its findings could lead it to use corrective powers such as ordering erasure of personal data, or imposing an administrative fine (see the previous section Enforcement).

If a supervisory authority makes such a legally binding decision based on a person’s complaint, but that person disagrees with the supervisory authority’s decision, the person can appeal that decision to court. A complainant can also go to court if the supervisory authority does not handle their complaint, or does not provide an update on the progress or outcome of the complaint within three months.

Good to know when using cloud services

If a controller organisation fails to comply with the GDPR because a cloud service it uses was not designed properly, the controller organisation can still be held liable.

For example, let’s imagine a cloud service which was never designed to let the controller organisations using it provide a person with a copy of their data, or erase or restrict processing. In such a case, an affected person can still file a complaint to the supervisory authority against the controller organisation using that cloud service.