Achieving Data Privacy Compliance involves a dynamic process requiring the expertise of many roles, particularly legal and technical experts, and it ultimately revolves around the goal of data protection, particularly in technical systems. While this goal may be clear, the inner workings and overall structure of the compliance process remain under-researched. In particular, the roles involved in the process of data privacy compliance and the nature of the interactions between them have not yet been investigated or formalized in a structured manner. In this work, we present such a structure, based on a series of interviews conducted with privacy professionals with varying responsibilities in compliance programs.
Section 4, which culminates in our Privacy Compliance Structure (PCS). We conclude our work in Section 5, describing points of future work.
Modern privacy regulations, such as the GDPR or CCPA, establish guidelines for the responsible
handling of personal data and require strict compliance, i.e., "ensuring adherence of an
organization, process or (software) product to laws, guidelines, specifications and regulations"
[
We perform qualitative research following Grounded Theory methodology as described by Hoda
et al. [
4.1. Roles Through the interview study, three overarching categories of roles were highlighted, each of which participates in the privacy compliance process from a different angle. In the interview discussion, the goal was not only to learn about the role of the interviewee, but also about relevant interactions with other roles, including the responsibilities of these further roles. Following the interviews, these roles and their responsibilities were extracted, and they are outlined below. 4.1.1. Legal
Organization Large US media conglomerate Large German multinational software corporation US law firm Large US multinational tech company Small German data protection software company Large German multinational tech conglomerate Small German data privacy company International financial technology corporation Large US Tech Corporation Global Web Consortium German-based digital privacy consulting firm German-based consulting firm Large German multinational tech conglomerate British-based news corporation Chinese multinational tech corporation Indian-based law firm The first major role category consists of legal experts, which generally refer to practicing lawyers or legal associates, often specialized in data privacy or cybersecurity. These roles can be filled internally, or contracted to external legal counsel. The responsibility of these roles is to provide legal support and advice regarding the legal requirements set forth by relevant laws and regulations for privacy compliance.
Another type of legal role comes with the consultant. In the absence of or in supplement to lawyers, consultants are important to providing expert knowledge of the proper handling of data, also in light of relevant legal requirements. While consultants often may be a key point of the compliance process, these roles are often not practicing lawyers, showing that legal expertise may come in multiple forms.
A third type of legal role, although not explicitly legal, is that of the compliance team. Headed by a Compliance Officer, the compliance team is responsible for spearheading compliance activities, including assessing operational risk and ensuring that compliance steps are properly in line with data privacy principles. While the presence of such teams can be observed in practice, it is not clear how widespread such a unit is.
The process of privacy compliance also requires the involvement of technical experts, especially for the translation of legal requirements into technical solutions. As such, various technical roles were revealed to be involved, which we categorize under the term of Development. The first of these is the product team. Led by the Product Owner, the team is responsible for identifying and assessing potential privacy risks in a proposed product or project. Particularly with the Product Owner, this role becomes the "first point of contact" for ensuring privacy in a specific system.
Also important to the technical side of privacy compliance is the general role of architects. Software Architects are responsible for the design, rather than implementation, of systems, and it is in this phase where privacy matters must be first addressed. Architects may sometimes be specialized as Privacy (and Security) Architects, and also Enterprise Architects in larger organizations. In these roles, the design of privacy-preserving systems is crucial in the larger context of privacy compliance.
The role of experts in the Development category has been studied in the literature [
Further abstracted from the implementation of technical systems is the role of management,
which is separated from development. Such roles are tasked with the leadership and direction
with regards to compliance programs, ultimately giving the green light for compliance programs.
A concrete role often mentioned was the Chief Information Security Officer (CISO). The literature
also points to the newer role of Chief Privacy Officer (CPO) [
As a final group existing between the legal and technical roles, we define the category of GoBetweens consisting of roles of a more hybrid nature. Concretely, we identified two important roles falling under this categorization.
Particularly since the GDPR came into effect, the role of Data Protection Officer (DPO) has
become central to the compliance process. The DPO is appointed to steer and monitor all privacy
compliance activities, such as Data Protection Impact Assessments (DPIA) or awareness-raising
programs. DPOs can be internally filled, or also served by external persons such as consultants.
At the core of the responsibilities of this person lies the task of liaising between the letter of the
law and how this is interpreted in practice for organization-specific data processing activities.
With this, it is clear that the DPO serves a hybrid role, with a leaning towards the legal aspects.
Nevertheless, the multi-faceted responsibilities of the DPO include having technical knowledge,
as noted by Ciclosi and Massacci [
The relatively novel, yet rapidly developing role of Privacy Engineer is tasked with bridging
the legal-technical gap by providing technical expertise. While the discipline of Privacy
Engineering is not yet fully mature, the general role involves creating trust by protecting privacy
in technical systems and shaping organizational policy to facilitate this. Privacy engineers do not
necessarily need to be experts in the specifics of a system; it is their expertise in privacy design
principles that provides value to privacy compliance. As noted by Gürses and del Alamo [
The interviews also revealed other "external" supporting roles. On the regulatory side, supervisory authorities were indicated as important stakeholders. Within an organization, Marketing, HR, and Sales were also mentioned. Finally, the customer was often listed as a stakeholder, as the "true benefactor" of compliance efforts.
Between the three main categories of roles in privacy compliance come many interactions, consisting of the Technical-Technical, Technical-Legal, and Legal-Legal nature. In defining these types of interactions, we utilize our categorization of roles as introduced above. Thus, an interaction is reported if an interviewee mentioned a relationship between roles within the legal or technical role categories, or between the two.
Within the technical sphere of an organization, interactions occurring in the process of privacy compliance come in two general forms: vertical and horizontal. Vertical interactions refer to the role of management positions, which pass down decisions regarding data privacy, as well as provide support in liaison with legal experts. Architects may often interact with managers for matters regarding compliance.
More horizontally, privacy engineers will often interact with other technical roles, such as software engineers, in order to provide guidance and policy for the implementation of compliant systems. It should be noted that interactions also occur within a team, e.g., when privacy engineers of various specializations consult with one another.
As the process of privacy compliance is inherently interdisciplinary, technical-legal interactions are commonplace and almost necessary to ensure the success of compliance programs. The interviews highlighted that many of these interactions take place between legal experts such as lawyers and the technical leadership of an organization, i.e., management. In these interactions, the interpretation of legal requirements becomes very important for leaders to make informed decisions regarding privacy.
For other technical roles, not in management positions, the main point of contact regarding legal matters is the DPO. As access to the DPO is much more readily available than to lawyers, the DPO becomes a de facto Go-Between in bridging the technical-legal divide. This type of interaction, initiated by technical roles, can be useful to engineers with legal questions, or, specifically, to validate that legal requirements are being fulfilled in technical implementations.
An interesting question arises whether technical-legal interactions occur in the other direction, where legal roles initiate contact. While this type of interaction was not reported, it can be best observed in the close work of DPOs with Privacy Engineers or in cross-functional teams. Nevertheless, a more in-depth exploration of the legal roles in privacy compliance presents an interesting opportunity for future work.
A final type of technical-legal interaction comes with the existence of cross-functional teams. While this is not a common practice, such teams consist of members from different departments, including those that are more technically or legally oriented. These teams serve as an ideal place for cross-disciplinary exchange.
While legal-legal interactions were reported, such as those between consultants and lawyers, they are not expounded upon, as this is not the focus of our work.
Based on the insights obtained regarding the roles, responsibilities, and interactions of the privacy compliance process, we propose a structure to illustrate the process and the dynamics within. As such, we have created the Privacy Compliance Structure (PCS), presented in Figure 1.
The PCS was created as follows. Firstly, the descriptions of the roles held by the interviewees were consolidated, serving as the foundation for the structure. Next, the interviews were analyzed for mentions of other roles in privacy compliance; more importantly, the nature of interaction between this newly mentioned role and the role of the interviewee was noted. This helped to form the basis of the interactions seen in Figure 1. Finally, the major sections in the structure, e.g., Development, were positioned to facilitate the nature of the interactions, as described above. For example, the vertical interaction between Management and Development is clear, and the close work between Privacy Engineers and DPOs is also reflected.
In Figure 1, solid single-directional arrows represent designated reporting lines, whereas single-directional dashed lines represent indirect reporting lines (where direct interaction is rare). Solid bi-directional arrows denote exchange rather than reporting lines, and hollow bidirectional lines indicate that two roles may be served by the same person. Finally, a cyclical arrow denotes when exchange occurs within a team.
In this work, we outline the components that are part of the process of privacy compliance, namely the roles, their responsibilities, and the interactions within. Using these findings, we construct a Privacy Compliance Structure that mirrors the above-mentioned components. In presenting this structure, we hope to provide structure to the dynamic process of privacy compliance, particularly in the implementation of technical measures.
As suggestions for future work, we see that a validation of the proposed structure is necessary to boost the generalizability of the model. To accomplish this, compliance programs of various organizations, from large and small, as well as those in differing domains, should be studied. Targeted case studies may be a useful approach for this. In addition, as the field continues to evolve, the inclusion of novel and currently not considered roles should be emphasized. As such, we hope that our base structure can be refined, updated, and evaluated. This work has been supported by the German Federal Ministry of Education and Research (BMBF) Software Campus grant LACE 01IS17049.