17. Dezember 2018 - Fundamental approaches for implementing the GDPR

Basic data protection: a must


Just a handful of specific legal questions left to clarify in detail, then the responsible people will have fully implemented the General Data Protection Regulation (GDPR)? Unlikely. Here we set out the minimum requirements for implementation of the GDPR from the point of view of a supervisory authority.

Basic data protection From a technical standpoint, the GDPR is essentially all about reducing risks to the rights and freedoms of natural persons as far as possible (Image: Devenorr / iStock / Getty Images)

Some of the requirements should already be known to the majority of readers from a variety of contexts, whether it be legislative texts, specialist articles or presentations. Some they may never have heard of, or have heard different things about.

Ultimately, however, that is not the most important thing. The 25th of May 2018 did not represent the completion of implementation of a new law; rather, data protection-compliant design of processing procedures has only just begun.

There can be no end – that is the nature of the GDPR – instead it is about continual improvement and adaptation of careful handling of personal data to take account of changing conditions.

Below we set out a non-exhaustive list of the aspects that all data controllers must implement and that form the basis for further, more specialised requirements (for example data transfers to third countries, data portability, etc.).

Record of processing activities

Whether it is the baker around the corner, an online shop, a data handler or a major firm, everyone must keep a record of processing activities in accordance with Art. 30 GDPR.

If used correctly, the record is not a bureaucratic nightmare, but provides the data controller with a quick overview of the key questions surrounding his data processing. This includes, for example:

  • In which areas are personal data processed?
  • Why are the data processed (GDPR: What is the purpose of the processing)?
  • What type of data (GDPR: Categories) are they?
  • How long are they required, and when do they need to be erased?
  • Are there any service providers (in non-secure third countries) used?
  • How are the data protected against misuse?

The exceptions set out in Art. 30 Para. 5 on records of processing activities are inapplicable to virtually all companies as it is almost never the case that processing does not take place on a regular basis.

The website or payroll accounting is enough for this exception not to apply. In addition, data processing rarely falls into the category of „no risk“.

Little work for small companies

The GDPR applies to any processing of personal data, i.e. even to small and medium-sized enterprises (SMEs). Thankfully, implementation of the record of processing activities is easy to scale up and down.

This means that a small company, such as a bakery, can compile the record with very little work: in principle, all that is required to cover the handful of processing activities is a few sheets of paper, a look at the handouts from a data protection supervisory authority (e.g. and implementation of – perhaps existing – IT security measures, such as the latest software, passwords and correct disposal of data carriers.

Whilst the work involved is limited for smaller companies, things can look very different for data-driven companies or groups: with these primarily process-oriented companies, bringing the many business processes to an average level of abstraction – in line with the purpose of the processing – is a complex task.

Hundreds of processing activities can quickly accumulate, often involving many service providers or parent companies/subsidiaries. However, because these companies often have large legal and IT departments, the record of processing activities should be easy to compile.

When the record is compiled (in parts), the following aspects should be implemented and documented for each processing activity:

Obligation to inform

As compared with the old German Federal Data Protection Act (BDSG-alt), the GDPR features expanded obligations to inform. These are found, for example, in Article 13 (data collected from the data subject) and Article 14 (data obtained from a third party).

Because obtaining data from a third party is an extension of collection from the data subject, it is worth taking a look at the basis, which must always be implemented. What is important here is that the data subject only needs to be informed of what they do not already know (e.g. from the context).

The following formal aspects must be included, for example:

  • Name of the data controller
  • Contact details for the DPO (e-mail address is sufficient in the online environment)
  • Purposes of processing
  • Recipients of the data (incl. third country transfers)

Further information satisfies the principle of fair and transparent processing. This includes the length of storage, information on the data subject’s rights (access, rectification, etc.) and the data subject’s right to complain to the supervisory authority.

If companies or clubs do not collect data from the data subject (Art. 14 GDPR), they must add in the missing areas, e.g. the name of the data controller.

Don’t forget: your own website is best suited to this as it is a „point of attack“ for reprimands from (supposed) competitors.

Although it is still unclear whether data protection in accordance with the GDPR as grounds for reprimand will hold up or whether a competition relationship within the meaning of the Act Against Unfair Competition (UWG) applies – e.g. in the case of local clubs – this issue is likely to give rise to a period of uncertainty and head scratching.

PRACTICAL TIP: Should a concrete obligation to inform seem „absurd“, the best thing to do is request information from the responsible supervisory authority (on the website). It is likely that your interpretation is too narrow.

Legal bases

Every processing activity requires a legal basis. This means that a legal basis must be identified and documented for each processing task. The options available in accordance with the GDPR:

  • a) Consent
  • b) Contract
  • c) Legal obligation of the data controller
  • d) Vital interests of the data subject
  • e) Public interest
  • f) Balancing of interests

The legal bases cannot be exchanged at will (according to the current stance of the supervisory authorities). For example, if consent is revoked, the data cannot simply continue to be processed on the basis of legitimate interests.

Data processing on behalf of a controller

A list of service providers must be compiled for each processing activity. The crucial question when deciding whether a processing relationship exists lies in who „determines the purposes and means“.

  • „Purposes“ essentially means who decides what is done with the personal data;
  • „Means“ concerns the knowledge, other data and IT infrastructure that is employed.

If the activity of the service provider does not fall within the scope of data processing on behalf of the controller, transfer to him, i.e. to a third party, is not categorically excluded. However, a legal basis is required, as are corresponding contracts in many cases.

An important tip: Even under the GDPR it cannot be excluded that data controllers are essentially able to personally monitor contracted processors. Even though this issue will be less significant from 2019 when certifications become available, such a formal restriction would not be permissible.

Privacy by design

This principle essentially means that data controllers have to implement the principles of processing set out in Art. 5 Para. 1 by means of technical and organisational measures. The principles are

  • transparency,
  • purpose limitation,
  • data minimisation,
  • accuracy,
  • storage limitation and
  • integrity and confidentiality.

This is not a one-off task, but is assessed across the entire timespan of a processing activity, and may be adapted to take account of changing conditions. It concerns, for example, the selection of a piece of software, the planning of a marketing campaign or the implementation of a business idea.

Privacy by design also scales up and down well

Small companies can generally achieve a good level by means of roles/rights concepts (Windows standard) and pseudonymisation.

Large and data-driven companies, on the other hand, have greater hurdles to overcome. This is because the complexity of data flows brings complicated measures for minimising risks.

Security of processing

The GDPR places particular emphasis on protection against unauthorised processing of personal data. Unauthorised processing applies in the case of hacker attacks or ransomware trojans, for example.

Based on tried-and-tested information security methods, Article 32 deals with how data controllers ensure the protection objectives of availability, confidentiality and integrity. The primary measures for reducing the risk are pseudonymisation and encryption procedures.

In addition, however, alongside data and processes, IT systems must be protected and employees must be chosen carefully. Once again, security in harmony with the GDPR is a regular process of evaluation and improvement.

Notification obligations

It is good when personal data are protected against unauthorised or unwanted access as far as possible – but 100% security cannot exist, which ultimately leads to most companies needing to deal with the notification obligations set out in Articles 33 and 34.

The GDPR has significantly reduced the threshold for notifying a supervisory authority. It should be noted that data controllers have to report both security breaches affecting their own company, as well as those affecting all service providers (even sub- and sub-sub-service providers in an international context).

When notifying, the deadline of 72 hours – very strict: weekends and Christmas count unfortunately! – must be complied with. Here are a few typical examples of an obligation to notify the supervisory authority:

  • Hacking of a web shop
  • Ransomware trojans affecting a doctor
  • Infection by complex malware (in terms of the possibility of subsequently loading malicious code)
  • Theft/loss of a notebook (unless it is fully encrypted)
  • An open mailing list, if the context is significant
  • Accidental sending of letters
  • Software errors (e.g. ticket booking portal)

The data subjects only need to be informed in the event of a high risk. In principle, this is comparable to the old § 42a BDSG, except that there are no longer any limitations on specific categories of data.

„Non-notification“ is the exception

In the event of a breach of availability, confidentiality and integrity, notification is only not necessary if there is no risk to the data subjects. offers a risk matrix that has been agreed among German supervisory authorities. It labels „non-notification“ as an exception.

Data protection impact assessment

A data protection impact assessment (DPIA) is necessary when it cannot be sufficiently ensured and proven that the measures taken in accordance with Art. 25 and 32 GDPR are effective, or if the residual risk is still high despite the measures taken in all conscience.

This is likely to often the case for new technologies, i.e. innovations in a sector, for which there is no knowledge based on experience. Standard measures are also often not enough in the case of very complex processes that involve handling enormous volumes of data – Art. 35 Para. 3 GDPR describes this with the term „processing on a large scale“, for example.

The question of processing on a large scale is playing an important role at present. This is because, in this case, a data protection officer (§ 38 BDSG-neu) would have to be appointed, e.g. where health data are concerned.

Small local doctors are pondering whether 6,000 patients fall under the term „on a large scale“. This matter is also being hotly debated by the German supervisory authorities. However, there is a trend towards using the English term „large scale“ to bring clarity, as in this case the majority of doctors, psychologists, social workers, etc. do not fall under the DPIA obligation, and therefore do not have to designate a data protection officer.

Exception: Other prerequisites apply, such as the ten-person limit. If in doubt, simply go to the website of the responsible supervisory authority and research the state’s typical viewpoint on this matter.

When is a DPIA necessary?

The DPIA must be looked at in the context of the other GDPR articles on technical aspects, as otherwise the question as to whether an impact assessment is necessary – namely when it is likely that the risk is high – is difficult to answer. A slightly exaggerated example:

Let’s assume that a general practitioner in a small rural community is building a new practice. Everything is going great, except that the joiner is going to be four weeks late in delivering the sturdy front door. But the doctor is moving into the building with his paper files. The files are now accessible to everyone in (unlocked) cabinets because of the lack of door. The doctor hangs a sign saying „No entry“ on the door frame as a protective measure.

The question is: How high is the risk of the patient data becoming known to unauthorised persons? The unanimous answer should be „high“. So the doctor should conduct a data protection impact assessment, right?

He will need a team of security specialists, lawyers and construction engineers, as well as a lot of time and money. The result of the systematic risk assessment (that is all a DPIA is) is: he needs a sturdy door.

Should the doctor emotionally survive finding out this result – given the effort involved – he will, quite rightly, ask whether a data protection impact assessment was even necessary, given that it pointed out the obvious. The answer is clear: of course not.

DPIAs usually don’t apply to SMEs

An impact assessment is usually not necessary for SMEs, except, for example, in the case of very special data-driven business models such as big data, special apps or innovative technologies.

Nevertheless, SMEs also must briefly assess and document whether each processing activity is likely to involve a high risk (= DPIA). In large or data-driven companies, on the other hand, a DPIA is a matter that should not be underestimated.

Have-to and don’t-have-to lists

Supervisory authorities are required to specify processing activities that are likely to involve a high risk and for which a DPIA must therefore be implemented.

The first agreed have-to list (also known as a blacklist) was passed at the Data Protection Conference at the start of June 2018. It is available to download at

Lists of processing activities for which a DPIA does not have to be carried out will not come from the German supervisory authorities at present. This is because the methods of risk assessment have not been sufficiently trialled.


A new feature included in the GDPR is accountability (Art. 5 Para. 2 GDPR). During inspections, data controllers have to prove to the supervisory authority that they are complying with the General Regulation.

In big companies, a management system is pretty much mandatory, whilst small companies and clubs have an easier time thanks to the record of processing activities: if all of the points set out in this article are implemented, documented and checked on a regular basis, that is usually enough as evidence under the GDPR.

Summary: everyone needs a solid foundation

Whilst the (unnecessary) fear of fines in the millions of euros may soon wane among small companies and clubs, the supervisory authorities will be getting involved in inspections more frequently.

We need to hope – and can expect – that the focus points of inspections and fines will also be aimed more at large companies and data-driven models than at small sports clubs and craft businesses, in line with the risk-oriented approach.

Nevertheless, it is advisable to take basic data protection seriously in order to be able to deal with a visit from the supervisory authority with confidence, should the need arise.

Andreas Sachs
Andreas Sachs leads the „technical data protection and IT security“ department at the Bavarian office for data protection supervision (BayLDA).