15. September 2018 - Duty & choice

How to check software for GDPR compliance


Today, nothing happens without IT support. As soon as personal data come into play, the GDPR applies – to both new and existing software solutions. What do you need to look at in order to assess whether a piece of software conforms to the GDPR?

How to check software for GDPR compliance Innumerable individual or integrated solutions across the country have been programmed and implemented or purchased as standard solutions. Where do they stand when it comes to GDPR compliance? (Image: NicoElNino / iStock / Getty Images)

When companies and administrations implement new IT solutions, it is ultimately unimportant whether they are independently created individual software or standard industry solutions that have been adapted by means of customizing, configuration and parametrisation. The starting point for a software check remains the same.

It also applies to existing solutions already in productive use. Also unimportant is the question which tasks and functions the software supports. It could be a single-user PC solution or the biggest ERP solution from the heart of Germany.

Logically, however, in the data protection context, it has to be about the processing of personal data.

With all forms of software, data controllers have to ensure that they are observing the requirements of the General Data Protection Regulation (GDPR), including the opening clauses in the new national law.

Developers and product managers of standard software should as far as possible remember to ensure that new releases and versions satisfy these requirements or make their implementation easier – something that can also create a competitive advantage.

More than ever before, the responsible data protection officer has to put the solutions through their paces, define requirements, adaptations and additions, and recommend restrictions or usage options.

What needs to be checked and how – duty

Legal basis

A fundamental check carried out in advance should already have found out that there exists an authorisation or, in the new terminology, an obligation to process personal data. This means that you need to clarify the purpose and legal basis of the processing (cf. Art. 5-11 GDPR).

It is important to think about which personal data is concerned here. For example, consider whether the data includes special categories of personal data (cf. Art. 9-10 GDPR).


Something that does not fall within the regular responsibilities of the data protection officer but is nevertheless important is the question as to whether co-determination on the part of a works council or employee representative is in place.

This is usually the case when software is able to record and evaluate employees‘ behavioural or performance characteristics.

Data processing on behalf of a controller

Another general check is the question as to whether a third party is necessary in order to use the software or certain functions. In this case it may be necessary to conclude an agreement on data processing on behalf of the controller (cf. Art. 28 GDPR).

However, it may also represent a case of the newly created possibility of „joint controllers“ (cf. Art. 26 GDPR). The Data Protection Conference no longer recognises the transfer of function that was possible under the old law.

Transfer to a third country

If data are transferred to a third country, check whether this is permissible and whether there is a sufficient basis for doing so (cf. Art. 44-50 GDPR).

It does not necessarily have to be active transfer by the operator. Also the manufacturer access with storage in the cloud is a possibility that needs to be highlighted.

Ask yourself the question which interfaces and direct and indirect export functions the application to be checked has.

Are all components necessary?

Now that you have revealed several fundamental structures of the software, clarify whether the authority or the company actually needs all of the functionalities, modules, interfaces, evaluations, etc. that the procedure to be analysed provides (cf. Art. 24 GDPR).

If not, recommend that the components that are not needed be permanently and demonstrably deactivated by means of customizing and configuration. This soon gives rise to the question as to which data within the actual technical processing need to be secured.

A logging concept can quickly summarise

  • which log files are required,
  • who is allowed to access them,
  • how they are evaluated and
  • how long they are stored.

Record of processing activities and data protection impact assessment

Another key component of a fundamental software check is checking whether the software has been entered into the record of processing activities and whether a data protection impact assessment has been carried out, providet that special categories of personal data are concerned or other prerequisites of the GDPR are satisfied.

This is easy, or easier, if you have a data model that highlights

  • all possible individual data,
  • their integrations and relationships,
  • as well as sources and origin,
  • possible recipients and
  • the different retention periods (cf. Art. 30 GDPR).

The data protection impact assessment (cf. Art. 35 GDPR) is strictly regulated in accordance with the General Data Protection Regulation. It represents an essential prerequisite for production.

Privacy by Design

The basic checks also include the question as to whether the software satisfies the newly positioned principles of data protection by design and by default.

Does the product only collect and process the data actually required? Do the chosen technical processes minimise the processing risks (cf. Art. 25 GDPR)?

Technical and organisational measures

From a technical security point of view, you should furthermore check whether the software is surrounded by sufficient technical and organisational measures to ensure secure processing of personal data (cf. Art. 32 GDPR).

Has the state of the art been taken into account (e.g. BSI directives)? Is there a coherent roles and rights concept to guarantee that only necessary rights are assigned?

Also look at aspects of the test procedure: is it sufficient to test with synthetic, pseudonymised or anonymous data, or is real data absolutely necessary?


Finally, the topic of „training and instruction“ needs to be addressed.

Sufficient training and guidance is required so that those who use the software are able to operate the program correctly. This also contributes to a safe and low-risk processing of personal data.

At all stages of the check, always remember the purpose of the processing and the scope of the processing.

This means that under certain circumstances individual checks may not be necessary, may not need to be as extensive, or even may need to be added. The risks of processing also play a role.

What needs to be checked and how – choice

Everything that has been on your checklist so far is compulsory. These are the basics that – essentially already rooted in the previous law – can now be found in Chapter II of the GDPR, Principles.

It is well known that the General Regulation strengthens the legal position of data subjects with new or more extensive rights. You must also subject these rights to a check in order to be able to prove advanced legal compliance.

Obligation to inform and right of access

Operators of a piece of software have to ensure that their solution takes account of both the data controller’s obligation to inform and the data subject’s right of access.

Test whether you can find the necessary information as if you were trying to access it as a data subject, and establish whether it is clear and understandable. This is the only way for your authority or company to meet the new regulations as the data controller.

After all, if you not informed yourself, you cannot provide the data subject with information „in the worst-case scenario“ (cf. right off access set out in Art. 13-15 GDPR).

Right to rectification and erasure

Requests for rectification and erasure of data are especially important. Check whether simple errors caused by transfer and recording errors can be corrected.

Also consider whether it is possible to erase data belonging to a data subject fully and across all systems (cf. Art. 16-18 GDPR).

In practice, this is an extremely complicated and complex right to implement and requires its own concept. It has to list all possible data, take account of sources and recipients, state the actual use, etc. – and ideally create erasure confirmation, taking into account the prior retention periods under the laws applicable in the industry.

This is a good place to use the data model again, which helped to compile the record of processing activities. This is one way to offset the effort involved in compiling such data models if they don’t already exist.

In this context, you should check whether the data processing can be restricted. This right of data subjects applies, for example, when there are different opinions about data or their processing before the data subject exercises the right to be forgotten.

weitermachen Data portability and automated decision-making

Finally, there are two further checks required because they concern direct rights under the GDPR. First is the right to data portability (Art. 20 GDPR). Does the solution guarantee that a data subject’s data can be exported summarised in a structured, machine-readable format? This is an inventory management requirement.

The second matter is automated individual decision-making as used in profiling, but also in traditional automated processing, which involves defining services that can be standardised (cf. Art. 22 GDPR).

This affects the healthcare sector, for example. Also taking into account the opening clauses used, there are certain rules that need to be observed in order to be able to use software in a legally compliant manner (cf. § 37 of the German Federal Data Protection Act (BDSG)).

A lot of work to get to the green light …

A whole host of checks and considerations and a fair bit of specialist knowledge and experience are required in order to implement this process conscientiously and finally reach an (internal) declaration of conformity.

It is a significant amount of work in the case of a small isolated solution or a single-user system. The nature of the beast means that the protection of the rights of data subjects is often poorer in these instances than with large systems and procedures. In the case of the latter, such a large amount of work is more reasonable in view of the other customisation and configuration work.

It becomes even more difficult in the case of large integrated solutions that are made up of specialised and general or overarching components.

Here, the checks must take place in parallel across all components of the solution so that you can ultimately reach a comprehensive level of overall conformity.

Developing individual checklists

This post should encourage you to compile your own checklist or your own inspection catalogue in order to be able to handle this work in a standardised manner.

A sample checklist based on the points presented in this post can be found here.

Call to manufacturers

Suppliers of standard software are being called upon to examine the extent to which they can and will offer their products already „GDPR compliant“.

They could supply data models, provide interfaces for data portability, or give recommendations on technical and organisational measures for meeting different security standards.

This will not replace the work of the responsible data protection officer, but can provide significant support.

Dirk Erdmann
Dirk Erdmann has been working as an internal and external official data protection officer since 2001.