The General Data Protection Regulation – organisational alignment of the Data Protection Officer

DPO according to GDPR

Introduction

GDPR significantly increases the existing data protection requirements by extending the territorial scope, the rights of individuals and the specific obligations of financial institutions.

In January 2017, we published a brief introduction to the scope, the major implications and changes for financial institutions and gave a recommendation for a three-step approach (see: https://en.bankinghub.comlounge.dev/banking/finance-risk/general-data-protection-regulation).

One of the focal points of the new Regulation concerns the appointment of a Data Protection Officer (DPO). The GDPR clearly stipulates in which cases designation of a data protection officer (DPO) is mandatory and what their typical responsibilities are, but only gives vague guidance on how they are appropriately positioned within the organisation.

In this article we aim to explain the main responsibilities of the DPO, a role which has been heavily extended in comparison to existing local legislation (such as the German Federal Data Protection Act[1], Article 4f of German law) and outline some principles of organisational setup. We also discuss the relationship of the DPO with other areas such as Information Security (InfoSec) and discuss pros and cons of allocation within the organisation’s hierarchy using examples from the market. Finally we give our recommendation while taking GDPR requirements and practical experience into account.

The role of the DPO

The DPO role is primarily described in Article 39 of the GDPR. They shall monitor compliance, inform and advise data controllers, data processors and all employees who carry out personal data processing, cooperate with supervisory authorities and act as the single point of contact for data subjects regarding their rights.

In short, they are responsible for monitoring that all requirements of the institution are met. A short overview of main tasks is shown in following figure.

Figure 1: Main responsibilities of the DPO

In order to properly meet these responsibilities they will need to be appropriately embedded within a dedicated department or to have suitable supporting roles established within the organisation. The GDPR provides some guidelines on how this organisation needs to be set up in Article 38:

GDPR regarding the position of the data protection officer

Figure 2: GDPR reference points regarding the position of the data protection officer

Interpreting Article 38 and especially the impact for financial institutions, it becomes clear that the DPO will need support from top management and possibly a direct reporting line in order to avoid or navigate potential conflicts. The conflict between a firm’s digital strategy and the DPO’s GDPR mandate could be an example of this. The DPO’s role in compliance with privacy rights and creating transparency might have a significant impact on IT implementation costs and time, product launching, marketing initiatives, etc. The law also stipulates the independence of the DPO, in particular their freedom to discharge their responsibilities without fear of penalties.

Organisational positioning of the DPO

Because the DPO will be “…involved, properly and in a timely manner, in all issues which relate to the protection of personal data” (Art. 38, 1) they will need to be significantly involved in data management topics (CDO and data governance organisation), information security and influence on IT for all data processing and systems that deal with personal data. The relationship to information security is especially important since the two areas will have an overlap of systems, data and functions which will be visible in policies and monitoring functions. Nevertheless, the DPO and InfoSec mandates are different. While DPO focusses on personal data protection (and thus the rights of individuals), the main focus of InfoSec is the protection of the institution itself by avoiding any critical disturbance in overall IT processing.

Internal collaboration

Figure 3: High-level internal collaboration model

All institutions will need to answer the question of where to position this new role in the organisation while keeping the needs of both internal relations and cooperation in mind, as well as the overall guidance of organisation setup and embedding as specified by the Regulation.

Our point of view is that both the data controller and the data protection officer as monitoring authorities need to be supported by almost the whole organisation in order to achieve compliance with the GPDR. We see strong overlaps at least at the beginning of the journey with existing data management networks and already established roles and responsibilities.

As an example, BCBS #239 requires the implementation of several data ownership roles as well as stewardship, which could serve as first supporting roles in the new privacy collaboration model.

Practical examples

Most of the institutions we are working with have already started (or some even finished) a pre-study or implementation project. The question of who takes on the DPO role needs to be discussed at top management level while taking the existing organisational setup into account. We recommend that the organisational positioning and collaboration model should be defined early in the implementation phase to in order to prevent a lack of guidance and support by the nominated board member, especially during first steps of implementation. We regard this as even more important because several strategic decisions will have to be taken (such as the level of GDPR ambition to reach by the time the directive comes into force in May 2018) that require the backing of senior management. An overview of DPO positioning in selected peer banks presents a very heterogeneous picture with clear advantages and disadvantages to each approach.

Figure 4: Observed options

When assessing the chosen structures, it is useful to refer to the main aspects mentioned in Article 18.

Looking at Peer A it seems that the data privacy organisation, where the DPO is settled, has limited access to the Board, i.e. there is no direct reporting line. Also the DPO organisation is merged with other functions and not explicitly dedicated which might impact resource access. Furthermore, the different level of InfoSec might create issues.

Peer B has created a direct (albeit dotted) reporting line to the top management and thus seems to have sufficient attention and commitment. They have also established a separate data privacy department, but settled below InfoSec on the third level which might be a threat to independence and may lead to conflicts with InfoSec.

Peer C also lacks a dedicated department, as the DPO function is settled within a department. In this example, because the DPO function needs to execute operations, it might also deviate from the kinds of topics that the future DPO home “Regulatory Affairs” is used to and may have low resource allocation. The location seems to be also slightly distanced from related departments such as InfoSec.

GDPR deep dive—how to implement the ‘right to be forgotten’

A brief outline of implementation aspects

Read more »

Finally looking at Peer D, it seems that the main criteria have been considered. Direct access to management and active involvement seems to be ensured, a dedicated department with good access to resources seems on its way and InfoSec is very close, so collaboration and alignment should be easy.

Conclusion

Our recommendation would be to find a home for the DPO within the CRO area of the non-financial risk and compliance group with a dedicated department on the third level, but with an additional direct reporting line to the board member. This would be closest to the chosen setup of Peer 4. A close relationship with InfoSec and overall areas responsible for data management is beneficial. We would now open a discussion of where to position the InfoSec area. Information security is (or should be) a well-established function and as it focuses on guidance and monitoring of measures for disturbance-free infrastructure, it is naturally settled in the area of CIO/COO. However—as discussed above—we see the need for close collaboration and interaction and thus recommend establishing regular exchange and alignment on initiatives and issues.

Figure 5: Recommendation

Our recommendation above of an allocation of the DPO function to the CRO area is based on the fact that GDPR compliance will need a risk-based approach, in which the institution focuses on main processes, functions and systems that have a high risk of data breaches. For most institutions—where the time to change the organisation and to automate systems, design privacy and default is so short—there will be a need to focus on the main risk areas of data privacy. Once the DPO organisation is finalised and the processes and systems are under control, a less risk-based approach will be suitable and positioning within another C-suite portfolio might be reasonable.

[1] BDSG: Bundesdatenschutzgesetz (German Federal Data Protection Act)