GDPR in the context of cloud computing

GDPR in the context of cloud computing

Privacy regulations regarding data protection” are both a challenge and an opportunity. A key indicator for “GDPR maturity is the data protection mindset within companies and the level of data protection provided, which means what, where and how business-critical workloads operate on cloud infrastructures.

For many companies, the GDPR is still seen as a complex project. Legal, technical and organisational challenges brought about by the GDPR have proved stressful, resource sapping and ultra-difficult to maintain. Particularly in the case of large migration projects in the cloud computing environment, in the IoT environment or in big data scenarios, day-to-day business leaves little time to afford the correct attention data regulations require.

However, in addition to numerous implementation challenges, the GDPR also offers the opportunity to excel by redefining and implementing new data protection and IT security strategies, especially in the context of cloud computing.


As a result, the topic of cloud computing raises many questions in the context of the GDPR. In technical terms, cloud computing is a data processing contract. Hence, the cloud user should be fully aware of the way their data is always processed. Cloud providers and resource providers only support their functions and are dependent on the legal requirements of the responsible authority. In other words, both cloud providers and businesses must meet the minimum legal requirements for each cloud service under the GDPR.

Special attention should be focused on the ability of your cloud solution to meet Article 28 and Article 48. In light of the US Cloud Act US cloud service providers cannot guarantee to meet Article 48

“Any judgement of a court or tribunal and any decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognised or enforceable in any manner if based on an international agreement, such as a mutual legal assistance treaty, in force between the requesting third country and the Union or a Member State, without prejudice to other grounds for transfer pursuant to this Chapter.”


Seize the moment 


How to take advantage of the potential challenges behind the GDPR? There are two main questions. On the one hand, companies need to know which cloud providers they can trust to fully comply with the above articles.

On the other hand, companies need to know which technical and organisational measures they must take in order to be “GDPR-compliant”.


Opportunities and obligations for CISOs – the right cloud partner


The right cloud partner can be a valuable sparring partner in the light of GDPR, since with their expertise in compliance and security they can assist your company on its journey towards GDPR Compliance

If you apply a multi-cloud strategy, you need to assess the data protection policies of each cloud provider.

Hybrid and multi-cloud approaches are much more complex to coordinate and therefore may present a higher data protection risk. The multitude of different cloud providers, especially in the public cloud environment, makes it difficult for CISOs to ensure GDPR compliance. GDPR compliance is only as strong as the weakest link. For example, a breach or non-compliance by a single cloud provider within a multi-cloud deployment can undermine all efforts for a successful GDPR compliance.


Six Key Criteria


Here is a quick set of criteria you can use to evaluate your potential or existing cloud partners in terms of GDPR compliance:


Security and Privacy


A first necessary step is to assess to what extent the provider is able to comply with your IT security requirements. One easy way cloud providers can demonstrate compliance with security and “Privacy by Design” is by being ISO 27001 or ISO 27018 certified


Risk Management


Companies that work with a wide range of critical data must provide sufficient guarantees (in accordance with Article 28 of the GDPR Regulation) that the data controller uses “only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.

Hence, you need to make sure that your cloud provider is conducting regular audits for the review, scoring and evaluation of technical and organisational measures to guarantee the security of processing. In addition, you need to make sure that the cloud partner grants the right to audit to their customers. For EU companies appointing a EU member state sovereign owned cloud service provider ensures that your data is in safe hands and will not be handed over to a 3rd country court for example as this would expose the cloud service provider and company to large fines under the GDPR.


Data Location


Knowing the location where your data is being stored and processed is important. Yet, not all cloud partners provide you with the necessary transparency related to the cloud locations. Note that the cloud provider’s headquarters might not necessarily be the location where your data is hosted. In addition, your data may be moved between different cloud locations in the background, without letting you know. This may be part of the Terms of Service of the cloud partner. Finally, cloud service providers may store data within multiple location and some of these may be outside the EEA. As a Data Controller you need to define a multi-country cloud strategy to adhere to adequacy requirements as well as data localisation laws.


Security Features


The GDPR requires a slew of data protection safeguards, from encryption at rest and in transit to access controls to pseudonymous data  and anonymization. In order to achieve this, the easiest way is to choose a cloud partner that has enough security features to choose from such as backup, encryption, access control policies and others. If your cloud partner does not have such policy, you need to take care of the security features yourself.


Data Ownership


As a customer of a cloud provider you are the Data Controller which means you must maintain control and ownership of your own data. This can be achieved by signing a Data Processing Agreement with your cloud partner to guarantee that the partner is adhering to the data privacy protection requirements as per the GDPR. You can either draft your own or check if your cloud partner has created a DPA as a standard part of the Terms of Service. The advantage of using your own is that you can specify the type of personal data and “special” data collected. No matter if you use your partner’s DPA or your own, make sure that the terms state clearly that the Data Controller (i.e. you) owns the data and that the Data Processor (i.e. the cloud partner) will not share the data with third parties.


Deleting Data


You need to make sure that once your contract with the cloud partner has ended, you can download/erase the data and that the cloud partner will delete the data once you’ve terminated the service. Some cloud providers, especially when they are ISO-certified, have defined a standardised policy for deleting data after contract expiration. Try to find out how long it takes for the cloud provider to delete your data.

A data governance framework  as found in Relentless GDPR247   ensures a detailed  pathway to compliance that is easily maintained  and has built in continuous improvement.


Relentless GDPR247

Importance of Third Party Due Diligence in the Data Privacy Arena

Importance of Third Party Due Diligence in the Data Privacy Arena

Organisations are realising that failure to protect customer data is creating long-term business problems. One of the biggest is the fear of being unable to manage the fallout of a data breach involving a third-party processor.


Consumer reaction to data breaches


In a recent survey 69 percent of 7,500 consumers surveyed from France, Germany, Italy, U.K. and the U.S. say they have or would “boycott an organisation that showed a lack of integrity for protecting customer data” the concerns are real.

Furthermore, 62 percent of consumers felt inclined to blame the company (controller) certainly not a third party processor — if they lost their personal data.




Placing your data, the cloud, doesn’t mean you wash your hands of all your responsibility. With the introduction of the GDPR, third-party risk became even more heightened. If the data handler or data processor suffers a breach, you, the data controller, would almost certainly be held accountable. However, if you are going to work with third parties and you have done your due diligence, the regulators are obviously going to look on that very differently.

The recent low-cost airline Lion Air group found 30 million records posted online including passport details, names, addresses, contact details etc. It seems that an AWS bucket container was not secured and was left open.

With the Asia region still playing catch-up with privacy laws the fines imposed and the obligations to report the breach and more importantly the data subjects are sketchy to say the least.  It is not certain yet whether the Lion Group or any of the third parties involved were subject to GDPR. If it were to be the case the fine and damage of the brand could result in a large dent and could threaten its operations.

Quite often security is an afterthought. Data centre hosting can be myriad of ample complex contracts, data centre for example owned  by one company, operated by another, with a contract to yet another and everyone points fingers at each other  .

From a legal standpoint, there can still be issues with cloud service providers.

Most controllers concentrate on two requirements of their processors

  • Processor will follow the processing  instructions, and
  • that they will keep the data secure.

But  third party due diligence needs to go further and deeper.


A full 3rd party due diligence audit should take place, and this option should be clearly stated in data processing addendum’s / SCC’s (Standard Contract Clauses).

Under the GDPR, serious breaches must be reported within 72 hours — not almost a year, like Uber. If a data breach carries a “high risk of adversely affecting individuals’ rights and freedoms” the regulation is even more strict saying a breach must be reported without “undue delay.”

There only exception is for cases where a data controller judges that the breach is “unlikely to result in a risk to the rights and freedoms of natural persons,” but even in this case the breach must be thoroughly documented internally, along with the reason for not informing a DPA, something a DPA can at any time ask to see.

A large percentage of data breaches reported were found not to have met the criteria of reporting, because companies possible rushed the decision process in fear of missing that 72-hour window.


There are already notions that organisations are comparing which would be the most lenient authorities, so a multinational for example may choose to report a breach to an authority with less enforcement powers.

Third parties are very often the weak link in data security. According to some reports, third-party failure plays a part in 63 percent of all data breaches.

However, the headlines about breaches always centre upon the controller and rarely mention the third-party processors that may have played a part in the breach.


Third party due diligence frameworks


The process approach

Life cycle phase 1: Planning—Management develops plans to manage relationships with third parties.

  1. Life cycle phase 2: Due diligence and third-party selection—The enterprise conducts due diligence on all potential third parties before selecting and entering into contracts or relationships.
  2. Life cycle phase 3: Contract negotiation— Management reviews or has legal counsel review contracts before execution.
  3. Life cycle phase 4: Ongoing monitoring—Management periodically reviews third-party relationships.
  4. Life cycle phase 5: Termination and contingency planning—Management has adequate contingency plans that address steps to be taken in the event of contract default or termination.


Relentless Privacy and Compliance Services outsourced DPO service manages all third party contracts and due diligence.


Find Out More

Data Privacy Defining a Strategy beyond the Anxiety of Receiving Fines

Data Privacy Defining a Strategy beyond the Anxiety of Receiving Fines

Make deliberate choices about how you are using personal data


Organizations have encountered a demanding year since the GDPR came into full force on the 25th of May, 2018.  Following sixteen months  of the GDPR we recommend organizations take some time to explore the possibilities that a good personal data strategy may bring, as well as the course ahead. We list five key steps to devise a personal data strategy that reflects your organization’s values and vision


1. Determine your stakeholders and their stakes



First and foremost: it is crucial to get an understanding of the context that may influence your organization’s strategy. Ask yourself who your main stakeholders are in both the organization as a whole, as well as within the privacy and data management function. This can include investors, board members, as well as the Data Protection Authorities, but don’t forget that your clients and suppliers also have a big stake in the personal data strategy. After having identified your main stakeholders, determine what their stakes in the business and privacy might be. Different stakeholders will have different views on the ethics surrounding the processing personal data. Your customers may expect you to deal with personal data carefully, and to provide them value while using their data, even at the ‘cost’ of some of their privacy – as long as it is transparent. Pressure groups may focus more on adhering both to privacy principles as well as the rule of the law at all times.


2. Determine the company’s risk appetite when it comes to using personal data



With stakeholder stakes and motives in mind, you should reflect what the organization’s risk appetite is when it comes to privacy. It can be of value to keep the rising public awareness on privacy in mind when defining your risk appetite. The way your organization is viewed by the public in relation to privacy can have long-lasting effects on the organization as a whole; in both a positive, and negative sense. Imagine a scenario where your organization is featured on a newspaper’s front page – what would you not want to see written about your organization when it comes to privacy? Additionally, think about what you would like to see written about what your organization has done well, whilst keeping the risk of additional attention in mind when you encounter mistakes.


3. Develop a vision owned by the business



Based on the stakeholder analysis and risk appetite it is time to start thinking about the vision of the organization as a whole. Imagine your organization in five years’ time, how do you want it to have developed? What roles do data and privacy play, and how can they support this development? Do current regulations affect the business vision? Data is providing incredible opportunities for organizations to grow and mature, the possibilities are endless. Therefore, it is important for your organization to understand what these opportunities are and what impact they can have.

An important word of warning for this step is to involve all relevant internal stakeholders in the development of this vision, as well as the role that personal data and privacy may play, since all parts of organizations will deal with personal data and privacy in some capacity.


4. Determine the impact of your personal data strategy



After developing your initial vision, make sure you understand what impact it may have within your organization. It is tempting to draft a strategy with far-reaching, but non-committal statements: ‘we will use personal data to improve our customer engagement dramatically’, or ‘consent will be the basis for all of our processing to remain transparent’. However, both statements lack value without committed underlying actions; requiring systems, processes, capabilities, and projects, to facilitate the change to get your strategy to work. There should always be an assessment of what your strategy actually means, which should ideally be supported by data.


5. Take into account future trends


Central to strategy is the element of the future. A strategy can contain a road map, or a vision of your organization and plan of action and timeline of your organization’s future. New trends may affect the impact of your personal data strategy, or your newly formulated personal data strategy may become completely irrelevant if your organization turns to new ways of working. You may want to keep in mind the fact that all types of data may soon be ‘personified’. Or the fact that societal awareness of privacy issues is growing. These can all influence the way you are dealing with personal data, and your stakeholders.
Developing a personal data strategy is a complex and time-consuming task, but it is one that can propel your business forward, and prepare it for the future.


More information?


In one of our previous articles, we discussed the key ingredients to a good privacy strategy. For more information around how you can build a personal data strategy that reflects your organization, feel free to contact  us


Contact Now

Top Ten GDPR Principles No 7: Data Portability

Top Ten GDPR Principles No 7: Data Portability

Data Portability a Legal obstacle or opportunity?


Data portability creates a new right for individuals to have more control over their own data. This new right could lead to considerable costs for organisations, but it also provides a strategic opportunity if implemented in the right manner.


Introduction: GDPR obligation difficulties


According to the IAPP Annual Privacy Governance Report 2016 data controllers considered  three aspects of the GDPR most challenging to implement in their organization: the right to be forgotten, data portability and gathering explicit consent. In this article we will elaborate on why the implementation of the GDPR and the right of data portability  represents a risk but also a strategic opportunity for your organisa


What is Data Portability


“Data Portability” is

  • The ability and capacity to export data collected or stored digitally concerning a data subject
  • The ability to receive data concerning the data subject and to allow another controller to receive portable data.


The Data Portability requirement entails both a technical design requirement and a data subject rights requirement. From a technical perspective, data controllers will need to ensure their systems, connected products, applications and devices that collect and store information on data subject also have the added functionality of porting and transmitting data. In some cases, this will require controllers to tweak or redesign some systems, products, applications and devices. Furthermore, the new porting functionality must export data in a structured, commonly used and machine-readable format so that reuse of the data is possible.


Data Portability a New Right


From a data subject’s right perspective, the right to data portability creates a new right for individuals to exercise more control over their own data. It enables individuals to receive personal data concerning him or her, which he or she has provided to a controller.

Thus, data controllers will need to establish and implement processes, in addition to added systems and digital propositions/products functionality, that aid in processing data subject requests whether in manually or in automated fashion. After receiving the data the individual must be able to transmit this data to another controller without creating additional burden or hindrance to the previous data controller. The right to port data also entails that where technically feasible, the personal data will be transmitted directly from one controller to another.

Please be aware that the right to request a copy in a machine readable format is only possible if the data concerned was

  • Provided by the individual to the controller;
  • Processed by automated means, and
  • Processed based on consent or f
  • Fulfillment of a contract.


Linked to other rights


Data portability is part of a larger spectrum of data subject rights: access to and rectification or erasure of personal data, the right to object to decisions based on automated means, as well as notifying data subjects of a personal data breach.

Again, data controllers will need to implement supporting processes to be able to comply with these requests. For a data controller the process to carry out a request to port data could imply that you must facilitate different actions that are similar to the execution of other data subject rights.

  1. You may have to give the individual access to the personal information so that he knows what personal data is being processed
  2. You could have to rectify inaccuracies if the individual requests so; and
  3. You might have to erase all the personal data (compliant with established retention schedules and legal contracts) if the individual asks to transfer his data to another service provider.

Therefore three other data subject rights could be impacted when processing a data portability related request. Note however that the right of access, rectification and erasure are not similar to the right to data portability, it merely could imply that the data controller uses the same processes for these rights as it would need to facilitate the right to data portability.


In Practice


In practice this means that you have to have the ability to provide your client or customer with a copy of all the personal data that you have regarding him or her; and the ability to transfer the data to another data controller or service provider. The data that you have regarding a costumer or client is interpreted as all the data that the individual has provided actively and knowingly. This includes information the individual has provided to you by using the service or device (for example, location data or heartbeat from a fitness tracker). This could therefore be a large collection of data.

Furthermore the data must be provided in a way that facilitates reuse. For example, email must be provided in a format which preserves all the meta-data to allow effective reuse. Providing emails in PDF format would not suffice, because this is insufficiently structured for reuse. To comply with a request for data portability could be time consuming and lead to considerable costs for many organizations that have not already adopted a privacy by design approach to the design and build of their systems and digital products and propositions.


Large impact


The reason why this right is expected to have a large impact on your business, is that it alters the relationship between  the data subjects and data controllers. data subjects are enabled to manage their data across different platforms, via for example a direct download tool or application. Eventually the platform that the individual prefers shall receive all the personal data. If you are not the preferred platform you might be obligated to transfer your data to a competitor and potentially be requested to erase the (valuable) data you have collected over the years. This leads to more competition between data controllers and should be taken into account when determining your business strategy.


Make it an Advantage


  • Try to be efficient. Controllers must be able to comply with the request without undue delay and in any case within one month of receipt of the request. If you implement a process to port data, you should implement a procedure to process other individuals’ requests in accordance with law and provide extra services, for example by guaranteeing more data security.
  • Aim for the competitive advantage. Think about developing a user-friendly tool or interface that involves the individual and gives them more transparency, insight and control over their own data than other competitors.


This right gives customers the ability to switch service providers more easily, make sure they transfer their personal data to your organization and not your competitor’s.


Top Ten GDPR Principals No 6: Pseudonymization within profiling

Top Ten GDPR Principals No 6: Pseudonymization within profiling

How pseudonymization can be of benefit you and your customers


Today our article focuses on pseudonymization: what is pseudonymization and how is it different from – the more commonly  known – anonymization? How can you use pseudonymization when you perform profiling and how can you use it on your data? How can pseudonymization be of added value to both your organization and your customers


What is pseudonymization and what is profiling?


Pseudonymization uses a form of encryption to translate identifiable parts of personal data to unique artificial identifiers, so-called pseudonyms. It aims to decouple the “personal” in personal data. This makes the data ‘anonymous’ within a limited context. Outside of this context the person can still be re-identified. By using pseudonymization you are applying a security measure to the personal data you have in order to prevent linking that data to the original identity of a person.

Pseudonymous data can still be traced to the data subject. You may need external information to do so, but all pieces of the puzzle still exist, just not all in one place. With anonymized data on the other hand, the original source data is deleted and therefore inaccessible and irreducible.

Profiling according to the GDPR means “any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person”.

Profiling can also be used for predicting the data subject’s behavior and can be a valuable direct or indirect marketing tool. Note that the GDPR provides that data subjects shall not to be subject to decisions based solely on automated processing (including profiling) when this processing has legal or similarly significant consequences for them. You can only carry out this type of profiling where the decision is;

  • Necessary for entry into or performance of a contract.
  • Authorized by union or member state law applicable to the controller or:
  • Based upon the data subjects explicit consent.

Additionally if your processing falls under Article 22 ensure you:

  • Provide data subjects with information about the processing
  • Provide a simple transparent way for individuals to  ask for human intervention and to challenge the decision.
  • Carry our regular checks on the systems to ensure they are working as expected


How your company or organization can apply pseudonymization to its advantage


Pseudonymous data is suitable for a great range of analytical activities, research projects and for statistical purposes. Because not all personal data is exposed, it decreases the risk of abuse of the exposed data in the case of a data breach. The GDPR sets more relaxed standards for data that is pseudonymous as compared to personal data and seems to be nudging companies and organizations to use pseudonymization as a method of securing the personal data they process. Moreover, when data is pseudonymous it is less like to “significantly affect” the data subject or produce “legal effects” for the data subject, because the data subject can be identified less easily.

If you apply profiling in your organization, pseudonomyzing the data used in the profiling will be subject to the more relaxed standards mentioned earlier. Pseudonymizing the data may provide a “suitable measure” to safeguard data subjects’ rights, freedoms and legitimate interests. Profiling may also have positive effects for your clients: based on the information your clients have provided and your profiling exercise, you may be able to offer an identifiable group of clients products aimed specifically at that group.

When applied correctly pseudonymization can offer more data processing possibilities, including profiling, than if the data were to be processed without applying pseudonymization as a security measure. You need to keep in mind, however, that it does not render the data anonymous. Pseudonymous data is still considered to be personal data and you need to treat it as such. Even if you have pseudonymized data, in case of a data leak, you may still be obliged to inform the affected data subjects.

If your company are applying these methods within your data processing activities then the Relentless comprehensive GDPR assessment service will identify any gaps and provide the remediation steps needed to ensure compliance.


Book your GDPR Comprehensive assessment now 


Find Out More


Top Ten GDPR Principles No 5: Security Principles and Breach Notification

Top Ten GDPR Principles No 5: Security Principles and Breach Notification

What does the GDPR say about how you should secure personal data? 

Making sure that personal data is processed securely is an important aspect of privacy. And as security measure can take up two-thirds of your efforts when dealing with privacy, you also want to be efficient. So what does the  General Data Protection Regulation (GDPR) say about security?


Modern security thinking



Once upon a time, security meant that you had a firewall to keep the bad guys out, and that every user had a password of no less than six characters to make sure their accounts could not be compromised. Those days are long gone. We now know from modern security thinking that taking only preventive measures (like firewalls and passwords) are no longer enough nor efficient. Security these days means you are able to prevent your digital assets from being compromised, but also able to detect when something threatens them and able to respond to incidents to bring the situation back to normal.

Now in the General Data Protection Regulation (GDPR) the security section was extended . Security is now described in three articles (art. 32, 33 & 34), and it has been extended with breach notification obligations. Taking a closer look at Chapter IV, Section 2 of the GDPR, what does it actually say?


Secure the data you process



Under the regime of the GDPR you still have to make sure that you properly secure the personal data you process. The basic description of how to do so is unchanged compared to the definition in the Directive.  Security is again described as a risk management process: you should first assess the risk, then look at what is possible in terms of security, and after having balanced risk versus costs, define your security measures. Nothing new there, and by the way: proper information security has always been that way. There are however some aspects to take into account.

  • First, there is the notion that you should asses the risks for the rights and freedoms of natural persons, and not, say, the financial risks your organisation might face when the security of personal data gets compromised. You can of course include the latter, but including the former is a must. Security risk assessments regarding personal data should at least consider the impact of security failures on the individual – all the rest is optional.
  • Second, the GDPR gives a number of examples of security measures. Pseudonymisation [1] and encryption of personal data are suggested as good security measures, as is the fact that security is about the three pillars  Confidentiality – Integrity – Availability-and about being resilient to disruptions. Further, disaster recovery and having processes in place to regularly assess the state of your security measures are also suggestions given.
  • Third, security is no longer the responsibility of the controller alone. The processor is addressed as well in the security articles of the GDPR. The processor now has an obligation to apply proper security measures independent of the controller. This also means processors can be addressed directly by the supervisory authorities when their security fails and are no longer shielded by the controllers.

[1] The GDPR defines pseudonymisation as “the processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information.”



Breach notification



Added to the  GDPR is the notion of breach notification: in case (preventive) security measures are breached and personal data is unlawfully processed, the controller must report such a breach to the supervisory authority within 72 hours, and possibly to affected data subjects as well. This is the case unless you can establish that the breach has caused no actual risks for the data subjects or other individuals. 

Although  in the GDPR, this breach notification requirement is a well-known mechanism. It has been part of the ePrivacy Directive for some time now, meaning that telecommunications companies in the EU already deal with this on a daily basis. Also, a number of countries, the Netherlands among them, currently have breach notification obligations. As a result, numerous guidelines have already been published on how to establish whether a breach is severe enough to require notification, and if so, how breaches should be notified.

Having said all this, in case you do suffer a security breach (and it is not a question of whether it will happen to you, but when), breach notification should not be at the top of your mind. Responding to the breach should be, taking into account all actions that need taken care of: fighting possible intruders, establishing extent of the damage and restoring the situation back to normal. Notifying the breach to the supervisory authority is one of the elements of your response, but probably not your first.

To make sure that breach notification is properly executed, it should be firmly embedded within and throughout the whole of your security incident response plans. And, as with all other response processes, for breach notification a sub-process should be defined, including roles and responsibilities, process description, checklists, etc. This has the added advantage that, when security response plans are practised (you do practice, don’t you?), breach notification is automatically taken into account, as it should be.





What does this all mean? Should you now encrypt and pseudonymise every little snippet of data you processes? Should you redefine your entire incident handling processes making it revolve around breach notifications? No, that would be the wrong reaction.

You should resist those urges and keep acting like you always did (or should have done): make sure you perform proper risk assessments and then define your security measures based on these assessments. Address technical and organisational security measures and importantly, measures in all three areas of prevent, detect and respond. Lastly, part of your response measures should include the breach notification processes.


Relentless privacy and GDPR Compliance Assessment features all core areas with GAP Analysis and Remediation actions


Privacy Email Alert 

Get the latest GDPR News delivered to your email box.


Find Out More

Top Ten GDPR Principles No 4: Maintenance of Records of Processing Activities ( ROPA))

Top Ten GDPR Principles No 4: Maintenance of Records of Processing Activities ( ROPA))

What is the impact of maintaining  (ROPA) under the GDPR?


In this blog we focus on the technical and operational aspects of how organisations can create an overview of existing data processing activities. For some countries this is not an entirely new requirement, as organisations in for example the Netherlands and Belgium are already familiar with the obligation of notifying processing activities to the local Data Protection Authority.

This  responsibility for organisations, laid down in article 30 of the GDPR, requires a full overview of the processing activities that take place within an organization, but also requires these activities to be documented accordingly. This will require a proactive approach from, and collaboration within, organisations.


What does this  obligation entail for controllers?


Each controller has a responsibility to maintain records of all the processing activities which take place within the organization. These records (which need to be in writing, as well as in electronic form) must contain all of the following information:

(a)    the name and contact details of the controller and where applicable, the data protection office;

(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)   the transfers of personal data to a third country or an international organization, including the documentation of suitable safeguards;

(f)     the envisaged time limits for erasure of the different categories of data; and

(g)    a general description of the applied technical and organisational security measures.

Furthermore, the controller or the processor (please refer to the next paragraph) need to make the records available to the supervisory authority upon request.


And what about processors?


In general, the GDPR does not only require more responsibility from the controller, but it also requires more responsibility from the involved data processors. Therefore, this obligation is also applicable to processors. Each processor will have the responsibility to maintain records of all categories of processing activities carried out on behalf of a controller, containing:

  • 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 and the data protection officer;
  • the categories of processing carried out on behalf of each controller;
  • transfers of personal data to a third country or an international organization, including the documentation of suitable safeguards;
  • a general description of the applied technical and organisational security measures.

Operational and technical measures


Organising records of all the data processing activities that take place within in your organization, could pose a challenge.  Especially when these kinds of processing activities take place decentralised within different departments or business units. How can this stream of information best be coordinated, where should records be stored and more importantly, how should these records be maintained and kept up-to-date? Below a few practical tips and tricks are outlined.


1.       Involve the business


As data processing activities take place across your organization, it is key to localise the stakeholders which play a role at the beginning of the development or design of a product, process, system, application or project. These people have the main insight into the data processing activities and will be of extreme value to create and maintain the overview. Involve the business when your organization starts to think about the underlying process that is needed to generate these records. Make them aware of the benefits and the added value for your organization.

2.       Design (and align) a process, with clear roles and responsibilities


When you have your stakeholders involved, the next step is to determine the process in which the records must be obtained, checked, added to a central register and kept up-to-date. Be aware that lot of the required information will most probably already be obtained by performing Privacy Impact Assessments (DPIA’s). If there is an existing supporting process, explore to what extent this new process can be aligned. This will coordinate the required effort, and will prevent the business from providing the required information twice.


Also, make sure that clear roles and responsibilities are defined when the process is being developed. Think about responsibilities with regard to the collection of the required information, including the information into a centralised register and updating the information in the register when needed.


Do not forget to involve other competences as well, such as IT, compliance, procurement and legal, as they could also greatly benefit from the information. Think of the contracts in light of the procurement process in case processors are (going to be) involved. The information will be of great value in settling data processing agreements.


3.       Create a central register for the records.


The records that must be kept, should be stored in a centralised manner. Depending on the infrastructure of the specific organization, explore how to support the fundamental process. Preferably, organisations should not “seek refuge” in Excel sheets, as easy as it might be – but rather use a proper tool. In this way one centralised system will provide a full overview of the processing activities that take place within the organization. Of course in this scenario people have to be aware of the proper technical measures, such as access and authorisation rights (not everyone should be authorized to change or alter information). The market for privacy tools is expanding rapidly, and it is good to think about the technical requirements and possibilities within your own organization.


Is this obligation a burden or could it become a valuable asset for organisations?


This requirement under the GDPR will require some extensive effort. The organising part  requires a lot of the business, but also of the privacy professionals involved. To convince the business of the added value of these records – besides the fact that it is an obligation of which non-compliance could lead to fines up to EUR 10.000.000 or 2% of the total worldwide annual turnover – will take time. Keeping in mind the development of the process, but also exploring and implementing the technical measures, it will be a time consuming process. Moreover, don’t forget to keep track of existing processing activities: not only new data processing activities must be recorded, but also the activities that are taking place at the moment (and maybe have been for years).

However, there is also something to gain. The records will provide an overview of all data processing activities within your organization, and therefore enable organisations to get a grip on what kind of data categories are being processed, by whom (which departments or business units) and for which underlying purposes. This knowledge will allow organisations to make connections internally, join efforts or projects with the same or equivalent goals and / or challenges and it can result in increasing control over data processing activities. This will provide insight into risks and required mitigation actions, and will inevitably result in empowering organisations to do more – and in a well-ordered manner – with the available personal data.

Relentless GDPR 247  is an ideal compliance platform for decentralised teams in different timezone’s  access and collaboration is easy making article 30 ROPA maintenance  seamless.


GDPR/247 Find Out More

GDPR/247 Pricing

Top Ten GDPR Principles No 3: Privacy By Design and By Default

Top Ten GDPR Principles No 3: Privacy By Design and By Default

A good idea Now Established


The General Data Protection Regulation (GDPR) changed European privacy rules significantly. The introduction of the concepts ‘Privacy by Design’ and ‘Privacy by Default’ are two of these changes. Although a new  legal requirement under the GDPR, these concepts are not new. Considering privacy from the start of the development process is essential to address privacy successfully.


Essential part to the GDPR


The GDPR changed European privacy rules significantly. The introduction of the concepts ‘Privacy by Design’ and ‘Privacy by Default’ are two of these changes. Privacy by Designs holds that organisations need to consider privacy at the initial design stages and throughout the complete development process of new products, processes or services that involve processing personal data. Privacy by default means that when a system or service includes choices for the individual on how much personal data he/she shares with others, the default settings should be the most privacy friendly ones. Although Privacy by Design and Privacy by Default has become a legal requirements under the GDPR, these concepts are not new. Considering privacy from the start of the development process is essential to address privacy successfully.


Increasing efficiency by thinking of privacy in advance


The GDPR requires organisations to consider privacy at the earliest stage. Privacy must be one of the ingredients of a new product or service, rather than the icing on the cake that is added at the end. This might seem complex, but it is actually easier than applying privacy considerations after a design is fully developed. When you think upfront about what personal data you want to use, for what purpose and how you will do this legitimately, it reduces the chance that you discover at a later stage that embedding privacy is technologically challenging, expensive or even impossible.

The application of Privacy by Design will therefore make the development process more efficient. Knowing what data you want to use, and giving data subjects a choice on how their data is used by applying Privacy by Default, makes it easier to be transparent those data subjects. And transparency is key when it comes to earning the trust to collect the data in the first place. In other words: applying Privacy by Design and Privacy by Default is simply a good idea. That is why many organisations already have incorporated these concepts in to their development processes.


Embedding privacy in the design process, where to start?


In order to embed privacy in the design process several aspects must be taken into consideration.

  • Operate within legal boundaries and be accountable

Under the GDPR organisations are not only responsible for adhering to privacy principles, they must be able to demonstrate compliance with them too. A privacy strategy is essential to make choices early in the development process regarding how you want to deal with privacy within your new service or product. Assess upfront if the idea can be executed within the relevant legal boundaries. A good instrument for doing this is carrying out a Data Privacy Impact Assessment (DPIA). A DPIA will help you identify privacy risks within your new design. Don’t forget to keep your DPIA findings. This will allow you to demonstrate your rationale behind certain decisions at a later stage.


  • Think of ethics


The ethical aspects of the concept must also be taken into consideration early on. An organization should determine how transparent it wants to be on its data processing and how much it wants to know about data subjects involved. A helpful questions is: would you use the product or service yourself?

  • Communication is key


Communication towards data subjects is very important to address at the initial design stages and throughout the complete development process. Communication lines must be clear, also when something goes wrong. For data subjects it must be clear where they can turn if they want to know more about the processing of their personal data and how they can exercise their rights.


  • Data security, quality and retirement


And of course it is important to think about adequate security measures, how the quality of data can be guaranteed and what will be done with the data when the product or service retires.




Successful implementation of both Privacy by Design and Privacy by Default requires that employees – especially those involved in the development of new products and services – have enough basic knowledge on privacy. Clear policies, guidelines and work instructions related to data protection should be developed and a privacy specialist should be available to assist in applying these requirements. The development method (agile, waterfall etc.) used within the organization must be taken into account, in order to apply the concepts throughout the whole development process. This will enable the development teams to take appropriate measures in the relevant phases. And finally, when a design has been completed, it must be adopted by the organization and monitored and maintained throughout its lifetime.


Privacy by Design and by Default, what is not to like?


Mandating Privacy by Design and by Default is the formalisation of a good idea. The GDPR is aimed to give data subjects more power over their personal data. Implementing Privacy by Design and Privacy by Default clearly reflects that aim. Offering the most privacy friendly option as a default setting will give people an actual say over which parts of their personal data can be used. The incorporation of Privacy by Design in the development process is the only way to apply privacy successfully. For organisations these concepts provide an opportunity to increase efficiency and gain data subjects’ trust. What is there not to like?


Privacy Email Alert 

Get the latest GDPR News delivered to your email box.


Subscribe Now