“ Those things are written by lawyers, and programmers are reading that.” Mapping the Communication Gap Between Software Developers and Privacy Experts

To ensure data-privacy compliance, it is common for companies to consult privacy experts for the identification and communication of privacy requirements to software developers. However, developers often fail to fulfill those requirements resulting in companies regularly being fined for violations due to non-compliance with privacy data regulations. To investigate why software developers struggle with the implementation of privacy requirements and explore their communication modality, we conducted a qualitative semi-structured interview study with 30 participants involving 10 software developers, 10 privacy experts, and 10 team coordinators with an average experience of nine years in the privacy communication and implementation process within a company context. We found a communication gap between software developers and privacy experts, suggesting a lack of proper procedural steps during the software development process to guarantee that the privacy requirements have been adequately addressed. We also uncovered that since privacy requirements were mostly communicated in a uni-directional manner, they were often perceived as a hindrance during software development, thus fostering an adversarial relationship between privacy experts and developers. Therefore, in order to fulfill the experts’ requirements, software developers requested concrete steps to take during the software development process, as observed in the security field. However, privacy experts often lacked the technical knowledge to provide such instructions. This work contributes an explanatory theory on the communication gap between software developers and privacy experts. We discuss common obstacles in the communication of privacy experts and software developers and provide guidance on how to address them.


INTRODUCTION
Since the implementation of the General Data Protection Regulation (GDPR) in May 2018, at least 1300 fines (as of November 2022 [31]) have been issued for violations or non-compliance.Five years and over two billion euros in fines later [31], software developers still struggle with implementing privacy requirements [14,46,47,68,72,89,95].During the software development process, the burden of implementing those requirements is often placed on developers who are rarely privacy experts and are confronted with challenges related to implementation [14,47,68,89].This motivated a line of privacy research investigating software developers' behavior with privacy tasks (e.g., [5,6,46,47,64,73,82,85,86,89]).To improve data-privacy compliance, companies are advised to hire or consult privacy experts who can translate regulations into privacy requirements for software products.For this work, we define privacy experts as individuals with a high level of knowledge or skill in data protection law and data privacy practices, e.g., by having a legal background or acting as a privacy specialist [17,58].While privacy experts can have the role of data protection officers (DPO) [23], they can also act as privacy consultants, e.g., for the Information Commissioner's Office (ICO) [55].
In this paper, we explored why software developers struggle to implement privacy requirements, focusing on the communication process between development teams and privacy experts.We conducted 30 semi-structured interviews with software developers, privacy experts, and team coordinators using Grounded Theory [18].Due to lack of time, spread out geographical locations, and high cost [2-4, 40, 44, 45, 76, 102], it is challenging to recruit software developers, specifically in the field of security and privacy research [1,28,44,54,74,87].We opted for an international sample experienced in different regulations to investigate privacy requirements relevant to a global context.Thus, based on previous research recommendations exploring different recruitment samples, methods, and platforms [39,69], we recruited a cross-section of participants from various locations with expertise in software development and privacy on Upwork.com[93].Theoretical sampling indicated that employees with team coordinator positions (e.g., team leads, product owners) in software development teams play a crucial role in the communication process, henceforth referred to as team coordinators.The online interviews were conducted via Zoom [24] and lasted 57 minutes on average and 28.6 hours in total.To provide deeper insights into the privacy practices and issues faced by parties involved in the communication of privacy requirements, we investigated the following research questions: RQ1: "What are developers', team coordinators', and privacy experts' perceptions of privacy requirements?"RQ2: "How does the communication of privacy requirements between developers, team coordinators, and privacy experts look like?"RQ3: "How do privacy experts create, and team coordinators and developers implement privacy requirements?" We provide the results of an exploratory qualitative study to understand how software developers and privacy experts perceive, communicate and implement privacy requirements within a company context.Our key insights are as follows: • Adversarial relationship: Developers often consider privacy requirements restrictive and hard to comprehend, resulting in an adversarial attitude towards experts providing these requirements.• Team coordinators: We found that communication between developers and privacy experts is almost non-existent and often indirect.Team coordinators play a critical role in acting as the pivot point for privacy-related communication.Further, individual developers might take responsibility for privacy requirements as privacy champions within the development team.• Differentiating between security and privacy: Supporting the findings of Hadar et al. [11], we found the distinction between security and privacy terminologies was often unclear on the development side.• Lack of privacy requirements verification: We found that verifying the implementation of privacy requirements is not a standard procedure within the companies our participants worked for.
Contributions.With this work, we contribute an explanatory theory on the communication gap between privacy experts and software developers grounded in the data collected from our participants.We highlight common obstacles in the communication of privacy experts and developers, discuss how to address them, and provide guidance on embedding privacy principles into the software development process.

RELATED WORK
This section summarizes related work focusing on the effect of introduced data protection regulations, the resulting challenges software developers face in implementing privacy requirements, and their behavior in regard to privacy compliance tasks.
Data protection regulation.The introduction of data protection regulation was studied broadly in the past [43,92,94].In 2018, Sirur et al. [75] studied how companies evaluated the introduction of GDPR and how prepared they were for this regulatory change.While some companies reported being prepared, others seemed to face difficulties keeping up with the legislation unless they strongly focused on security and privacy.Von Davier et al. [103] conducted an interview study with eight privacy professionals and found participants having issues with translating legislation into practice and the unclear job description of a DPO.They concluded that promoting the importance of privacy in companies is still necessary.Further research analyzed the causes of GDPR fines [49,68], showing human error and organizational issues as potential causes.There seem to be many layers of confusion within organizations.Therefore, exploring how different perceptions about privacy concepts manifest in corporations is crucial.
Challenges of implementing privacy requirements.Senarath et al. [72] conducted a study with 36 developers to identify challenges from embedding privacy requirements into software applications.They found developers lack formal knowledge of privacy practices such as Privacy by Design (PbD), Fair Information Practices (FIP), Data Minimization (DM), and Privacy Impact Assessment (PIA).Similarly, the studies conducted by Alhazmi et al. [5,6] examined the reasons preventing developers from adopting GDPR principles in their applications and software systems.They reported the focus on functional requirements, a lack of knowledge of GDPR principles, and supporting online tools as the main challenges faced by developers.
The research conducted by Tahaei et al. [82,85,86,89] showed that developers mainly face challenges when writing and modifying privacy policies, working or designing systems with access control, dealing with updates to platforms and APIs, and deciding on the privacy aspects of their projects.Further, they found that a negative privacy culture, disparate internal prioritization, missing tools, metrics, and high technical complexity pose barriers to implementing privacy -also observed in [64].Participants in the studies mentioned that informal discussions, strong support and communication from management and stakeholders, and documentation and guidelines helped promote privacy.Further, code reviews and practical training seem useful.
Research on websites' privacy notifications and cookie policies [26,48,79,96,97], as well as privacy information from apps [41,47,80] showed that software developers and companies were often unable to create notifications accurately.Further challenges were identified by analyzing general compliance to the legislation of apps [7,70] and monitoring conversations on privacy in online developer forums [63,84].For example, developers faced issues keeping track of the data collected by their application, often through third-party libraries, and thus struggled to provide accurate information for their users.
Developers' attitudes towards privacy adoption.Ayalon et al. [11] conducted an online survey with 101 developers to study their privacy decision-making processes.They investigated whether organizational, professional, or personal factors shape developers' privacy decision-making.They found that personal experiences as end users, organizational privacy climate, and compatibility with existing frameworks play a vital role in their decision-making.These findings align with Hadar et al. 's [36] interview study, adding that developers often confound data security with privacy challenges, thus limiting their perceived privacy threats.
Van der Linden et al. [98] conducted a study with 123 software developers to examine their attitude towards handling personal data, specifically, how concerned they are about privacy in the software development context.They found a mismatch between developers' attitudes and their self-perceived behavior.Further, developers' understanding of appropriate data collection and privacy principles and laws seemed to differ substantially.
The work of Balebako et al. [12] offered further insights into how mobile app developers make decisions relating to privacy and security, and examined the correlation between privacy and security behavior and characteristics of app development companies.They found that small companies were less likely to demonstrate good privacy and security behavior and that developers were often unaware of the vast amount of invasive data being collected by third-party tools.
Bednar et al. [14] interviewed six senior engineers to investigate their motivation and ability to comply with privacy regulations.They found that engineers believe privacy is a legal issue for which the legal world is responsible by providing legal frameworks and guidelines.There seemed to be a lack of perceived responsibility, control, autonomy, and frustration in interacting with the legal world.
In summary, past research showed that software developers often lack knowledge and have difficulties fulfilling privacy requirements.Therefore, they often do not implement or favor poor practices to ensure data privacy.While existing research suggests communication issues of privacy requirements, no research has been conducted yet to explore these with software developers and privacy experts.Our work complements and extends the growing line of privacy research with developers by examining the privacy requirements communication and implementation process between privacy experts, developers, and team coordinators.

METHODOLOGY
To provide insights into the collaboration of privacy experts and software developers, we conducted semi-structured interviews with 30 participants involved in communicating and implementing privacy requirements within a company context.
We were not aware of previous research on the communication between software developers and privacy experts.However, we had previous knowledge of data protection regulations and privacy-related research with software developers.Therefore, we used Grounded Theory by Charmaz [18,19] as the methodology for our qualitative research allowing an "in-depth exploration of a particular topic" [18] by "recognizing prior knowledge and theoretical preconceptions" [19].We recruited our participants online via Upwork [93] and asked them to fill out a short screening questionnaire, ensuring they were involved in communicating and implementing privacy requirements and had experience with privacy expert and developer collaborations.Participants fulfilling the requirements were asked to complete a questionnaire on their demographics and were invited to the interview study.All 30 interviews were conducted in English by the same researcher using the video communications platform, Zoom [24].Interviews lasted 57 minutes on average.The questionnaires and the interview guideline can be found in the supplementary material.

Interview Guideline
The semi-structured interview guideline consisted of three main parts.First (see Section 4.1), we were interested in how participants perceived privacy requirements.For this, we asked them to explain common privacy concepts software developers are most familiar with but often lack knowledge of, as suggested by Senarath and Arachchilage in [72]: Privacy by Design (PbD), Privacy Impact Assessment (PIA), Fair Information Practices (FIP), and Data Minimization (DM).We also asked for their experience with privacy concepts within the work context.Second (see Section 4.2), we asked participants about their role within the company, the company context, and how privacy requirements are implemented in the software development process (e.g., Who creates the privacy requirements?Who is responsible for ensuring that the privacy requirements are implemented?Do they understand the requirements?).We were specifically interested in communication processes between privacy experts and software developers.
Third (see Section 4.3), we presented participants with concrete privacy requirement tasks inspired by several blog posts (e.g., [32,52,71]) and asked for "think-aloud" walkthroughs.The tasks included technical examples for enabling access control for a hypothetical database and ensuring a maximum time for data retention.Further, collected data should not be used for advertising purposes.We contacted a commercial company involving software developers and privacy experts and approved that these were real-life examples the groups are often confronted with.Participants often referred to security practices when asked about privacy requirements within the first batches of interviews (9 with developers, 5 with privacy experts, and 5 with team coordinators).Since using grounded theory strategies allowed us to respond to new insights [19], we clarified that we were not asking for data security and provided data protection and data privacy definitions within the following interviews, according to GDPR [57,62].Data protection means "keeping data safe from unauthorized access" [57].Data protection principles are defined in Chapter 2 (Art.[5][6][7][8][9][10][11] [59] of the GDPR.For example, in the context of data minimization, it should be collected and processed only as much data as absolutely necessary for the purposes specified (see Art. 5(1)(c) [59]).Data privacy means "empowering your users to make their own decisions about who can process their data and for what purpose" [57].Data privacy rights of the data subject are defined in Chapter 3 (Art.12-23) [60] of the GDPR.We clarified we were not asking about data security according to [62] where "you're required to handle data securely by implementing appropriate technical and organizational measures" [61].However, we did not observe an effect of providing the definitions since we reached theoretical saturation between the 23rd and 25th interviews, i.e., no new properties emerged in interviews 25-30 (see Section 3.3).The final interview guideline can be found in the supplementary material.

Recruitment and Demographics
We recruited participants on Upwork.com[93], where software developers and privacy experts offer their services as freelancers.Participants were invited to take part in a short screening questionnaire asking for experience with communicating and implementing privacy requirements.Forty-eight participants filled out the screening questionnaire, of whom 34 participants were invited to the study.The 14 participants not invited to the study either did not fit the requirements (e.g., not having received or created privacy requirements in the past), expected higher compensation, or stopped replying to messages.Thirty-two participants completed the demographics questionnaire.One participant dropped out after filling out the demographics survey and was not interviewed.Out of 31 interviews, one was removed from analysis due to audio issues, leaving us with 30 interviews used for analysis.Participation was compensated with $75 via Upwork.Recruitment took place from September to November 2022.
The aggregated demographics of our participants can be found in Table 1 and participants' job titles in Table 2.We recruited 10 software developers, 10 privacy experts, and 10 team coordinators.Participants were from 16 countries, including India (6), USA (4), UK (4), Kenya (3), Belgium (2), etc.Most of our participants were male (25 male, 4 female, 1 prefer not to answer).They were, on average, 33.5 years old (min: 23, med: 33, max: 44), with an average of 9.1 years of industry experience (min: 0.5 med: 8.5, max: 20).Most had a Master (12) or a Bachelor (10) as their highest degree.Three participants had finished graduate school, and three others had a doctorate or PhD.Seven participants worked for companies with less than 100 employees, 9 worked for companies with 100 to 1000 employees, and 10 worked for companies with more than 1000 employees.Product management consultant D= Software Developer, E= Privacy Expert, C= Team Coordinator

Data Analysis
For data analysis, we used the core concepts of the constructivist approach by Charmaz [18] consisting of (1) initial coding: incidentby-incident, (2) focused coding: selecting categories from the essential codes, and (3) theoretical coding: specifying relationships between categories [78].Theoretical sampling advocates for "seeking and collecting pertinent data to elaborate and refine categories [...] until no new properties emerge", i.e., theoretical saturation is reached [18].In our interviews, participants often referred to team leads, project managers, or software developers in similar positions to be responsible for communicating privacy requirements.After conducting five interviews with developers and privacy experts each, we specifically invited team coordinators (see Table 2) involved in sharing privacy requirements with the software development teams to further elaborate the categories "Exchanged Information," "Communication Challenges," and "Communication Good Practices." Participants D2-D5 and E1-E5 mentioned this group being more directly involved in the communication process.Thus, our final sample involved privacy experts, software developers, and team coordinators.
The interviews were transcribed and analyzed by three researchers (R1, R2, R3) involved in this work.After coding the first four interviews individually, the three researchers developed one codebook (see Appendix E) for all three groups due to overlapping codes between the three roles.Disagreements were resolved by discussion, e.g., if code terms were similar in meaning but differed in wording (e.g., "tracking" and "cookies"), one common code was used.If code terms were similar in wording but different in meaning (e.g., differentiating between in-house and third-party legal teams), separate codes were produced, reflecting their intention.In the next step, R2 coded three, R3 coded two, and R1 coded all five subsequent interviews.New emerging codes and categories were discussed by all the researchers involved in this work in a further meeting.Finally, R1, R2, and R3 used the refined codebook to code the rest of the interviews, with R3 coding 8, R2 coding 22, and R1 coding all 30 interviews.
While the codebook was used to ensure consistency between coders coding different subsets, we note that "even if coders agree on codes, they may interpret the meaning of those codes differently" [50].Since codes are considered an interim product in grounded theory, we valued the differences in code interpretation and thus refrained from using inter-rater reliability coefficients as a measurement instrument.However, through our codebook's iterative and highly collaborative construction, we ensured that the coders agreed in their understanding of how to use the category system [50].We observed theoretical saturation between the 23 th and 25 th interview, i.e., no new properties emerged in interviews 25-30, and, hence, we stopped recruiting.

Ethical Considerations
The institutional review board (IRB) of our university approved our project.Participants were provided with a consent form outlining the scope of the study, the data use, participation risks, and retention policies.We also complied with the GDPR.Participants were informed that they could withdraw their data during or after the study without any consequences, as well as the practices used to process and store their data.We assured participants that we would only evaluate and publish de-identified data and quotes.All video and voice recordings were deleted after transcription.Participants had to give their consent before completing the demographic questionnaire and were additionally asked for consent and any additional questions before the interviews.They were also asked to download the consent form for their use.

Limitations
This section describes the limitations of our study, which have to be considered when interpreting the results.
We recruited participants on the freelance platform Upwork.This sample is certainly not representative of all developers and might not even be representative of other freelancer hiring services.Our profile analysis of potential participants for work experience in large companies was based on self-reported information and may suffer from several biases, including over-and under-reporting, sample bias, and social desirability bias.To mitigate social desirability bias, we specifically highlighted to participants that we are only interested in information about their communication processes and not judging their privacy knowledge, approaches, or processes in any way.While all participants were experienced in privacy processes at companies, some were only involved in projects as external councils or freelance developers for projects with limited time constraints.
Since grounded theory and theoretical sampling are not aimed at creating a representative sample, therefore, the results must be interpreted carefully concerning generalizability.Since we were interested in the communication of privacy requirements between developers and privacy experts, we mentioned privacy in our study description on Upwork.Thus, the software developers who participated in our study might be more privacy aware than the average developer.We observed a high rate of invited developers declining our job proposal on Upwork (15 of 31, 10 unanswered).A similar behavior was observed when recruiting team coordinators (6 out of 11, 3 unanswered).By contrast, this rate was very low for the privacy experts (2 of 12, 1 unanswered), indicating this target group might be more interested in working on privacy-related projects.

RESULTS
In the following, we present the main findings from the 30 interviews with developers, team coordinators, and privacy experts.We report results based on the categories of our codebook.We focus mainly on the perceptions of privacy requirements between the three groups, their communication, and how privacy requirements and the privacy process are handled within a company context.

Participants' Perceptions of Privacy Requirements (RQ1)
We asked participants from all three groups about their understanding of privacy, privacy concepts (e.g., PbD, PIA, FIP, and DM), and internal or external privacy regulations their company follows.Interestingly, we observed some participants focusing on security when asked about privacy.

Privacy Definition.
All privacy expert participants provided clear definitions of privacy.For example, E10 gave the following explanation: "Security is something that matters more with the infrastructure.So we have to put in place security measures in general, like cryptography, or secure our server somewhere [...].And privacy is a bigger theme where also there is a part of security because data should be secured.But there is also much more.
For example, the interest request or in general have a process in your company for being compliant." (E10) Team coordinator participants had a basic understanding of privacy and privacy regulation.Sometimes they had difficulties differentiating privacy and security issues (see Section 4.1.5).Seven developer participants lacked profound knowledge of privacy regulations or concepts but were responsible for fulfilling the privacy requirements (e.g., D1, D2, D4, D9, D10).

Privacy Concepts.
Nine privacy experts were familiar with all the concepts of PbD, PIA, FIP, and DM (e.g., E1, E2, E3, E7, E10).They reported to have used many privacy concepts in their previous work (e.g., E2, E3, E4, E7, E10).When asked about privacy concepts, eight team coordinator participants could not recognize all of them by name (e.g., C2, C3, C5, C7, C8).Three of them, however, reported to have implemented or used measures at their company without recognizing them by name (C1, C2, C7).Three others were unfamiliar with these concepts (C3, C8, C10).Five participants referred to consent, honoring people's preferences and control over data (C4, C6, C7, C8, C10).Further, four mentioned processes regarding data usage and storage (C5, C6, C9, C10).Three team coordinator participants specifically noted compliance with regulations such as purpose limitation or data collected on EU citizens has to be stored within the EU (C5, C7, C10).For example, C7 mentioned issues with data storage in the EU: "So whatever kind of system do we buy or do we want to implement [...], the company has to be in the EU.The data is not allowed to leave European Union.It doesn't matter what kind of project it's about.I have got personally a lot of problems with that because you're really bound by that and it's really, really hard because EU does not have everything that, for example, [...] the American companies offer." (C7) By contrast, five developer participants could not recognize privacy concepts by name but reported to have used them before (D1, D2, D5, D6, D7).Three others, however, were unaware of most concepts (D4, D9, D10).

Company Internal Guidelines.
All Privacy expert participants explained that companies often had internal guidelines concerning privacy.Six were responsible for creating the corresponding guidelines and privacy policies, which aimed to assist the development teams through the process of implementing privacy requirements (e.g., E4, E4, E5, E7, E10).
Six team coordinator participants mentioned templates, privacy policies, documentation, and questionnaires guiding them through the privacy process (e.g., C3, C6, C7, C9, C10).For example, C5 described the guidelines as follows: "So based on different requirements of these applications and the landscape, we have a set of questionnaires and set guidelines there.And they have to answer that, or the questions, they have to justify that in the questionnaire to what they think and what they want us to take into consideration while we develop this project, while you build or run this project." (C5) Three participants (C4, C6, C7) faced issues with the company's internal guidelines, such as the fact that they were written in legal language and often were "nebulous or ambiguous" (C4).Participant C7 described their issues as follows: "So very often I have to talk to them personally one on one or something like that, where they have to explain the question in a normal language.And then very often those, I mean, you can have a legal question which is being written in maybe ten words, and then those ten words [that] is one question, is very often broken down into five or six simpler questions where you have then now five or six questions which you have to answer.[...] I mean, it's not about language; it's not about, say, syntax, understanding of the question.It's more about contextual understanding." (C7) Seven developer participants mentioned internal documents being available within the company, helping them during the implementation of requirements.They used internal privacy policies, non-disclosure agreements, and documentation as guidelines (e.g., D4, D5, D7, D9, D10).

External Guidelines.
All privacy expert participants mentioned different legal regulations being considered in the companies they were working for, depending on the area the companies were geographically located and operating.Commonly mentioned were GDPR and CCPA if the companies were operating in Europe or the United States.Participants also mentioned different regulations of local legislation.For example, a number of different legislations were mentioned by E9: "[...] if it's the UK, then it's the Data Protection Act.[...] If it's the EU, then it's the GDPR, in the States it depends on which state you are from.So it can be anywhere from the California Privacy Act to the Digital Millennium Act, [...] Singapore as well, it will be in accordance with the PDPA, in South Africa, POPI." (E9) They were well informed about the laws companies have to follow depending on their service.While some were related to privacy, for example, the Health Insurance Portability and Accountability Act (HIPAA) [29] (E5, E6, E7), participants also mentioned regulations without a privacy focus.For example, E6 referred to the North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP) [25] or the European Non-GMO Industry Association (ENGA) [10].E7 mentioned special legislation concerning financial regulations, indicating that legal experts are often consulted beyond privacy laws.
All but one developer participant referenced external guidelines being used within their work context.D5 mentioned retrieving information from the Open Web Application Security Project (OWASP) [67].Four mentioned facing similar issues as the team coordinators concerning the understanding of guidelines and documents containing privacy advice by citing difficulties with legal language and missing definite descriptions or examples for their tasks (D1, D6, D9 D10).Five explicitly mentioned GDPR (D1, D2, D3, D4, D9) and four mentioned regional laws (D1, D2, D4, D8).4.1.5Security Focus.Privacy experts drew a clear distinction between security and privacy.Only E6 additionally referred to the term security when asked for privacy requirements.
By contrast, team coordinator participants often focused on security issues when asked about data privacy.Eight discussed encryption and authentication as part of privacy concepts and were concerned about potential attacks (e.g., C1, C2, C7, C8, C9).Still, five (C5, C7, C8, C9, C10) mentioned they saw a connection between the two topics: "Yes, as a point of the privacy [...] is ensuring the data are appropriately encrypted.We also want to ensure that we look into the minute aspects and understand the criticality of the data, and we [...] define a process where we ensure those details are not leaked out, and it's appropriately secured." (C5) Further, seven team coordinator participants referred to employees with security-related roles within the company as being also responsible for privacy (e.g., C4, C6, C7, C8, C10), indicating that security and privacy are often handled as one issue in practice.
While eight software developer participants referred to privacyrelated topics such as consent, storage of sensitive information, and authorized access (e.g., D3, D7, D8, D9, D10), five developers also referred to security concepts (D2, D6, D7, D8, D9).For example, encryption was mentioned as a common concept -arguing that if user data is encrypted, it is secure against attackers: "The biggest guarantee clients, companies, and agencies can be given is some form of encryption [...].However, no human without [...] knowledge of an encryption code has access to that data" (D2).Additionally, concepts like authentication, zero-knowledge proofs, and penetration testing were mentioned by four software developer participants (D3, D6, D8, D9).Thus, developers tended to think about security when asked about privacy as they seemed more familiar with implementing security measurements and preferred to be given specific security requirements instead of privacy guidance.While the mentioned security issues are important and contribute to the security of user data, they do not address the fair use of collected data according to laws and regulations, indicating that the focus often lies on attack scenarios instead of unintentional misuse by the data collectors themselves.Participants D8 and D9 identified security as necessary to achieve privacy.However, five agreed that considering only security is insufficient (D5, D6, D7, D8, D9).

Communication of Privacy
Requirements (RQ2) In the following, we describe involved parties in the communication process of privacy requirements, exchanged information, good practices, participants' wishes for improvement, and communication challenges.

Involved Parties
. When asked about privacy experts, 21 participants referred to in-house lawyers and DPOs (e.g., D5, D9, C3, C7, E4).Some larger companies have a department specialist privacy team, while smaller companies generally rely on third-party consultants, as mentioned by six participants (e.g., D7, C6, C8, E1, E5).Participants D9 and C9 mentioned contacting government entities to communicate on privacy.Privacy experts are tasked with collecting information about the project, referring to internal or external data regulations, and creating privacy requirements, which are often sent to developers in indirect communication according to 14 participants (e.g., D7, C2, C5, E1, E4).Nineteen privacy expert participants and developer participants explained they were often not directly contacting each other but via employees with leadership positions (e.g., D4, D8, E1, E2, E9).The role and background of these intermediaries can vary -team or product leads, product management, or product owner -often depending on company size.In smaller companies, the intermediary role is performed by a member of the leadership team or the company owner.Companies developing software at clients' request often included the clients in the communication on privacy and thus relied on them to provide the requirements as described by 11 participants (e.g., D3, D8, C6, C8, E4).Additionally, departments like sales, marketing, and human resources were also mentioned as being involved.All team coordinators we interviewed received privacy requirements from privacy experts and forwarded them to the software developers.Thus, they could take the role of a man in the middle.They had background knowledge of software development rather than privacy data regulations.
Nine participants from all groups (e.g., D2, D8, C4, E7, E10) mentioned experienced colleagues who were aware of privacy issues and could take responsibility for privacy within the development team.Past research referred to these individuals as privacy champions [82], raising awareness for privacy issues and being available for privacy-related questions during the implementation process: "So I think one of them [development team] comes from a privacy background, from a large, kind of data company in the US.And so I think that experience helps a lot because [...] within the engineering squad, they go to that particular individual." (C4) Further, employees whose job description indicated a focus on security were reported by nine participants to be active in privacy communication (e.g., D5, D8, C1, C6, E6).

Starting Point.
Participants were asked about their experience with starting points in projects addressing privacy requirements.Nine privacy expert participants mentioned they usually are involved from the beginning of a project (e.g., E1, E4, E5, E8, E9), five noted being involved in a project upon request (E1, E2, E4, E7, E8), and four described occasions where they became involved after the product was already deployed (E1, E4, E5, E6).

Challenges.
Six privacy expert participants (e.g., E1, E2, E5, E6, E8) mentioned that software developers often perceived them as a disruptive factor in software development: "You're always seen as the blocker" (E2); "I'm the enemy or I'm the one who says, No, you [CEO] can't do that" (E1).However, six privacy expert participants acknowledged that it is challenging for software developers to understand legal text, thus further affecting the communication between these two groups of individuals (e.g., E1, E3, E5, E8, E9).Missing information from the communication partners affected the privacy experts' ability to successfully accomplish tasks, such as providing privacy requirements to the development teams, was mentioned by five privacy expert participants (E4, E5, E7, E8, E9).
Team coordinator participants mentioned different challenges concerning privacy requirement communication.The overview of the high amount of different data regulations was mentioned to be specifically challenging: "because there are so many regulations" (C7); "And it is very long.Very tiring to read this APP [Australian Privacy Principles]" (C6).
The most common issue developer participants mentioned was that privacy was not treated with priority by the companies, which was mentioned by six developer participants (e.g., D1, D2, D4, D5, D9).
"Even in the larger organizations, I've never seen anyone actually do a proper formal assessment after it's been built, and it's working to see whether it meets the privacy requirements that were given earlier in the process.And the smaller clients, they didn't think of it.[...] They don't actually want to go and check whether they're, they're doing it properly, or whether I've done it properly, I suppose, really in that case." (D1) Four developer participants felt they were rarely involved in the communication process of privacy requirements (D1, D6, D7, D8) and requested someone they could contact concerning privacy requirements: "[...] the person to give you the information may be very busy and they just point you to a file [...] or they just give you the entire file and you have all of the clients' information in front of you, which you are not supposed perhaps to access." (D7) Additionally, three (D1, D9, D10) complained that the legal requirements were hard to understand for them "the HIPAA [...] those things are written by lawyers, and programmers are reading that" (D9).By contrast, privacy experts were perceived as disruptive and lacking the technical expertise by two (D6, D9) developer participants "He's [privacy expert] not technical like he doesn't have the software knowledge" (D6).Two also mentioned that good documentation of the communication process could help clarify the requirements (E7, E9).Additionally, three others wished for a "common language" (E2) and more understanding of legal requirements from developers (E1, E2, E8).

Good
Six team coordinator participants perceived that open communication with the involved parties and having a flat hierarchy could increase the quality of privacy requirement communication (e.g., C1, C3, C7, C8, C10), e.g., by also involving software developers: "we [team coordinators] prefer to have the software developer on call with the privacy experts" (C8).One also mentioned colleagues with whom they work closely as ample support: "Luckily, in my case, I have a few colleagues [...] who have worked very close to data privacy.And so I can kind of, I guess, collaborate with them" (C4).C2, C4, and C10 wished for more direct, proactive, and improved communication with privacy experts.Providing software developers more context might also improve the development process: "I think they [software developer] can always get more context around the problem" (C4).Besides, C5 mentioned that better communication tools (e.g., Issue Tracker Software) could also improve the communication process with software developers.
Four developer participants mentioned that discussing privacy issues openly with the involved parties positively influences their company and is helpful concerning the developers' challenges, such as missing information and the lack of communication (D1, D6, D7, D8).Additionally, six (e.g., D2, D5, D8, D9, D10) stated that the communication was perceived helpful when legal requirements were clarified "He [lawyer] will explain things in great detail and make sure the developer understands them correctly" (D9).Four developer participants felt that being part of the discussion, especially at the beginning of the software development process, might improve the communication of privacy requirements (D1, D3, D7, D8).This could be achieved by, e.g., "coming up with a communication department" (D8).Additionally, D2 and D6 noted that having clear protocols would support communication between all parties.In many cases, they were unsure how to reach out for clarifications.

Communication patterns.
We identified three main patterns participants described in the communication process concerning privacy as shown in Figure 1.While companies would not always stay strictly to one pattern and might employ solutions mixing elements from the patterns, the three patterns present the main ways of communication between the groups.
The first pattern (Figure 1a) was most common and described as a "one-way communication" if external privacy experts created the requirements, as they were often hired only to create the requirements and unavailable for questions.In these cases, software development teams only received the requirements and had to resolve potential questions themselves.In a second pattern, "artifact only" (Figure 1b), the communication between the privacy experts and the software development teams happened on the documents containing the privacy requirements.Software developers would leave comments or create issues if they required clarification, had questions, or found issues, to which the privacy experts would reply.Lastly, some participants described the process as very interactive (Figure 1c): software development teams and privacy experts would directly communicate with each other and discuss software projects and requirements aimed to be fulfilled by them.This would mean directly involving the employees from both sides in meetings and contacting each other with questions.Further, both sides could leave comments and discuss issues in the privacy artifact.

Creation and Implementation of Privacy Requirements (RQ3)
In the following, we describe the creation, implementation, and verification process of privacy requirements.

Exchanged Information.
To create privacy requirements for their projects, privacy expert participants reported requiring access to project information.Eight privacy expert participants mentioned they were given a product description covering the system's purpose, functionality, and technical requirements (e.g., E1, E2, E4, E8, E9).All but one privacy expert participant stated that they need to know about the collection of customer data (e.g., E1, E4, E5, E7, E10) or the storage of that data (e.g., E1, E2, E3, E6, E9).Additionally, seven privacy expert participants mentioned they need to know the 3rd parties involved in the delivery of a service or what security measures and policies are already in place (e.g., E1, E4, E5, E6, E9).This information is often collected from software development teams via questionnaires asking about sensitive information collected in different projects, as described by three participants (E1, E4, E6).The privacy experts evaluate the questionnaires and return them to the developers, with critical issues marked for the development teams to take care of.E7 and E8 mentioned OneTrust [56] as a tool to communicate the questionnaires for the PIA to the companies.Additionally, seven privacy expert participants reported performing risk assessments of the applications (e.g., E2, E4, E6, E7, E8).

Implementation.
When privacy expert participants were shown examples of data collection for advertisements, six stated the requirements represented what they would encounter as part of their work (e.g., E2, E3, E4, E6, E9).Four other participants noted that they are unlikely to work on such privacy requirements as their company is not involved in advertising (E1, E7, E8, E10).All privacy expert participants perceived the more technical requirements concerning microphone usage as realistic.However, two mentioned it would probably require a particular data collection form as they were unaware of a practical application at their workplace (E4, E8).Six privacy expert participants said they often send messages to the development teams and ask them to stop collecting sensitive data (e.g., E2, E3, E6, E8, E10).Three team coordinator participants mentioned they would expect privacy requirements to be more similar to functional requirements (C1, C3, C7).A key example concerned how "access control" was defined, leaving six unable to understand what was required to be implemented (e.g., C2, C4, C5, C6, C8).
"So I think in this example, like understanding [...] who are the users who get this access or who within the organization, what access type, what are the roles and responsibilities of that access?And then is it the whole table?Is it parts of the table?"(C4) Further, as described by C6, even seemingly simple requirements like implementing a maximum retention period might not be as straightforward as they seem: "So for example, that form is something that I deleted.But it's there in our backup and that form can be brought back into life after we restore our backup.So having that mechanism, checking that mechanism is important there." (C6) Three team coordinator participants would regularly remind their developer teams of the requirement to make sure audio data was not collected, (C7, C8, C10), with C7 reporting that they would further specify the requirements into tasks for the developers.However, five mentioned the example did not apply to their work context (C1, C2, C6, C7, C10), as they were not involved in collecting data.
Eight developer participants reported to be able to handle the two more technical requirements (e.g., D1, D2, D6, D7, D10).Like the team coordinator participants, seven developers perceived "access control" needing to be clearly defined (e.g., D3, D4, D6, D7, D8)."The first thing I would do would probably be to ask [...] what the access control should be, so what the requirements are for the access control, who what type of user can access what in that table?" (D6) Nine participants were generally able to describe technical details on the implementation of the requirements, for example, developing an automated script to take care of data deletion in case the retention period was over (e.g., D1, D2, D5, D7, D10).However, seven developers mentioned that the third requirement concerning advertising would not be a requirement they expect to encounter, as they had no control over advertising (e.g., D2, D4, D5, D6, D9).

Verification
. When asked about the verification process for the correct implementation of privacy requirements, eight experts would rely on the information given by other employees (e.g., E1, E5, E7, E8, E10).Five (E1, E4, E7, E8, E10) specifically mentioned they had to rely on other employees for verification since they lacked the technical skills to check the implementation: "If we speak about, you know, source code or going through the development that I would not be able to check it on my own because I do not have the technical background or knowledge.So I would of course ask for the responsibility of the persons involved." (E1) Further, E6 perceived his responsibility only in consulting.While four privacy experts reported that privacy issues might be rechecked during regular audits (E2, E3, E7, E8), five participants noted the lack of a verification process for privacy requirement implementation (E1, E4, E5, E6, E9)."It's normally just sent out and then that's it" (E9).Responsibility for the proper implementation of privacy requirements was shifted to software developers by five privacy expert participants (E1, E4, E5, E7, E8).
For our examples, four team coordinator participants often mentioned testing the privacy implementation themselves (C6, C7, C8, C9).In three cases, they reported creating dummy accounts with different access levels to check if access control was correctly implemented into a table (C6, C8, C9).Another potential form of verification mentioned was to check the implementation through code reviews, which were mentioned by three team coordinator participants (C7, C8, C9).
As already observed for team coordinators, two developer participants mentioned creating test cases themselves to verify privacy requirement implementation (D2, D8).For example, D8 would create accounts with different access levels and verify that the access control was implemented correctly.Similarly, code reviews were mentioned as a means of verification by two developer participants (D6, D10).4.3.4Challenges.Five privacy expert participants perceived that software developers often don't understand the privacy requirements (E1, E2, E3, E5, E9) they create for them and/or are unwilling to implement them: "It happened to me that I had a bit more difficult exchanges in terms of negotiation because simply they did not want to implement certain issues just because it didn't make sense for them" (E1).Three privacy expert participants also mentioned a lack of teamwork and clear responsibilities on privacy issues (E4, E6, E7), which hinders the privacy process.
"Some developers don't care about privacy, so the developers don't care about security.Some security people don't care about developing.[...] So people just don't want to learn a new task, or they would be like, it's not my job.I don't want to do it.Give that to a security person." (E6) Four team coordinator participants reported issues with the quality of the in-house privacy guidelines or guidelines provided by experts.They often had to ask for clarification of tasks and for detailed instructions on how to fulfill a particular requirement (C4, C6, C7, C8).C7 described issues that arose when they were required to give external users access to internal documents: "One requirement from two weeks ago [...] was, we have to enable downloading invoices to our customer.Those invoices contain data of our employees, what they have been working on for the customer.[...] So that's something that you cannot disable the access [...] from third parties outside of the company's network to this data.Now, it is about where is this data located?Because the requirement is often just like that.It is not a requirement.It's very often just a wish.[...] So some kind of data is stored in the archive, the other data in the ERP system and the third data is in Excel files and we have to gather all that data and then create a PDF document about it and then allow the document to be downloaded.[...] That is still in communication with the privacy officer because we cannot say with 100% certainty that that data is going to be always secure." (C7) Four team coordinators mentioned that high-complexity systems would make it very difficult to implement the requirements accurately, as changes to the system could influence many parts (C3, C6, C7, C10).Additionally, C7 mentioned that regular testing and code reviews help spot potential errors.C4 noted having an experienced person on the team would help during the implementation.
Five software developer participants complained about privacy requirements not being set into context and missing clear tasks or instructions applicable to the implementation phase (D2, D3, D6, D8, D9) "[...] I think most of the privacy guidelines I've seen are relatively ambiguous.You know, it's left on how you choose to interpret it" (D2).Vague guidelines were blamed for causing issues during implementation by two participants, as it was often unclear what was required from the developer (D9, D6).
"So there are a lot of scenarios that are not directly covered inside the explaining regulation, and that's where the back and forth with the regulating body comes because you need to give them examples.What if this, what if that, will that be compliant to you?" (D9) Still, four developer participants (D1, D2, D3, D9) mentioned providing examples as a positive factor: "And the people who were the first ones to implement GDPR, those are the ones who struggled, but the ones who come after them, it's much easier for them because they have examples" (D9).
Three developer participants complained that complex systems would make it very difficult to implement the requirements accurately (D2, D7, D8), as many parts of the system would have to be reworked: "So it means, and it depends on so many other components.So you have to go back and start redesigning or refactoring of the system code that you've done" (D7).Additionally, D2 mentioned having an experienced person on the team would help during the implementation.
4.3.5 Tools.Two team coordinators said using Amazon Web Services [8] (C6, C10) is a positive factor for implementing privacy.They noted many privacy-related issues were already taken care of by this service.However, C5 complained about needing better tools to implement privacy requirements easily.
Two developer participants referred to third-party tools with privacy features already in place.For example, they mentioned Microsoft Azure [53] (D9) or Google Cloud Services [33] (D6), explaining the services already fulfill many requirements regarding privacy.

Employment Status
We explored if participants' backgrounds might influence their perceptions of privacy communication and found that their current employment status might be relevant.Freelance or part-time privacy experts indicated to have experienced issues with missing information, such as technical information or information on data retention, to be especially challenging for privacy requirement creation.Further, freelance or part-time team coordinator participants called for more open and frequent communication on privacy than full-time employed team coordinators.Freelance or part-time developers mentioned difficulties fulfilling requirements in complex applications as it was difficult for them to asses how changes would influence the remaining system.They also mentioned communication issues such as missing context and clear tasks more often than software developers employed full-time.These findings highlight the existence of communication problems within companies, as outsiders (e.g., self-employed legal experts being hired as consultants or freelance developers) struggle to receive the information required for their tasks.

Privacy Requirements in Companies
While our analysis focused on the communication and implementation process of privacy requirements between developers and privacy experts, we also discuss the company context as a key factor.

Motivation for privacy.
Seven privacy experts had the objective for the company to be compliant with privacy regulations (e.g., E3, E4, E7, E9, E10) and two to pass potential audits by an external government entity (E2, E6).Eight mentioned the fear of fines (e.g., E1, E2, E5, E7, E9) and four named legal issues (E4, E6, E7, E9) as the primary motivators for ensuring the correct implementation of privacy requirements: "Right now, it's just everyone hopping onto the bandwagon to show [...] compliance so that we don't get penalized for it because the penalties are quite high" (E9).The objectives of team coordinators were compliance with legislation (C4, C6, C8, C9, C10) and fulfilling customers' wishes (C6, C7, C8).Two feared that bad privacy could tarnish their reputation and thus decrease their willingness to continue cooperating with the company (C1, C5): "Obviously, there's a reputational risk that our company would face if we're not handling our client data as a good steward" (C1).Similarly, while four developer participants' primary motivator for implementing privacy was also to comply with legislation (D2, D4, D7, D8), D3 explicitly mentioned the wishes of their customers as a motivating factor.

Company-related challenges.
Seven participants across all three groups reported that companies often were restricted by the lack of project resources (e.g., D3, C2, C5, E2, E4).This could include funding tools, having dedicated employees focusing on privacy issues, or hiring experts to advise the company, as well as the time they can set aside for privacy issues."Thebudget is quite limited, and for them [company], it is, let's put it this way, quite expensive to have extensive discussions with the privacy professionals" (E4).In addition, the difficulties increased for globally-operating companies, as there might be multiple different pieces of legislation that can apply.
"At [company], my role is the America's privacy officer, so I'm primarily in charge of U.S., Canada, Latin America.Right.And many of those countries now have privacy laws as well.Mexico, Brazil, Argentina." (E7) Further, the involvement of third parties or other departments can cause the company to rely on the privacy implementation of others without being able to verify that correct procedures are indeed in place to secure the collected information: "[...] as soon as you give the keys to this third party, to some degree, all bets might be off, right?" (E7) 4.5.3Privacy training.Eight participants from all three groups asked for awareness (e.g., D1, C3, C4, E3, E5), nine more experienced employees (e.g., D2, D8, C8, E1, E8), and seven for training (e.g., D2, C2, C4, E6, E8) within the company: "[...] the best way for any anyone in a tech company is to make sure that they are compliant with data privacy requirements is to really do the training to emphasize with them and provide them with the context.So they really need to understand why [...] are we implementing this?" (E8) This could also positively influence the company culture, which was wished for by E7, C6, and C7.

DISCUSSION AND RECOMMENDATIONS
In this section, we discuss our findings deducted from the results of our interviews.Considering our codes, memos, categories, and the experience with participants, we constructed an explanatory theory grounded in the data collected: An existent communication gap between privacy experts and software developers hinders the implementation of privacy requirements.Privacy experts often do not have an understanding of the software development process and developers' tasks.By contrast, developers do not possess knowledge of privacy laws, regulations, and voluntary codes of conduct.Privacy experts pass privacy requirements to developers, who struggle to infer from them what controls where to implement and how to verify whether the requirements have been met.Communication patterns varied from an interactive collaboration between experts and development teams to onesided communication, where requirements were handed over in a one-time manner while shifting responsibility and interpretation to the development team.

Obstacles Guidance
Figure 2: Obstacles and guidance to a Common Ground between privacy experts and software developers.
Common Ground Theory.Concepts from the field of psychology might offer insights into why this communication gap exists.For example, the Common Ground Theory [20,22] recognizes the need for communication parties from different perspectives and fields to understand each other.To communicate effectively, the parties involved in the communication process need to establish a Common Ground containing "the sum of their mutual, common, or joint knowledge, beliefs, and suppositions" [20, p. 93].This frame is mainly based on two sources: the Communal Common Ground, which is created through stereotypical assumptions based on attributes of the communication partner (e.g., age, gender, or profession), and the Personal Common Ground, which is built upon direct experiences with the communication partner.During the communication process of legal requirements in the software development process, two different parties are communicating with each other: legal experts, who are laypersons in the field of software development, and software developers, who are, in turn, laypersons in the area of privacy law, but experts in the field of software development.To effectively communicate, experts need to anticipate and adapt the laypersons' perspective [15,16].The Communal Common Ground might not be accurately established because experts can have different cognitive representations and knowledge systems about their fields compared to laypersons [15].Since we explored the communication between software development experts and privacy experts, these issues could disrupt communication in both directions.Further, the limited interaction of the two groups (see Section 4.2.5) could hinder the creation of a Personal Common Ground.The parties involved could switch to more direct forms of communication (e.g., face-to-face) [21] and establish privacy requirements and protocols in collaboration, ensuring that both parties address any unclear points.Establishing a common vocabulary and understanding of the risks might be essential for this.
Expertise of privacy experts and developers.Communication between software developers and privacy experts was perceived as complex due to the lack of knowledge of each other's fields of work.A potential cause for this could be an inaccurate representation of the Communal Common Ground, as outlined earlier.Often software developers had no legal background, and thus their understanding of requirements was hindered, e.g., by legal language (see Section 4.1.3).Therefore, software developers tended to confuse data privacy and security.They perceived privacy requirements as hard to understand due to the lack of context, unclear instructions, missing examples, and a language barrier.Further, they wished to be actively involved in the communication process and asked for a responsible party to contact when dealing with unclear privacy requirements.By contrast, privacy experts without software development experience faced difficulties understanding the software development process and technical details, making it hard for them to create privacy requirements to be used by software developers.Some privacy experts mentioned product artifacts or risk assessments as one of their main sources for creating requirements (see Section 4.3.1).Depending on how well or poorly the artifacts are described (e.g., documentation, test cases, or architecture), interaction with the development teams is highly relevant.During the walkthroughs, some privacy experts perceived measures taken to fulfill the requirements as "too technical" (see Section 4.3.3) to be able to verify the implementation.
Mutual perception.Privacy experts complained about software developers who were not motivated to comply with privacy requirements because they did not understand or care about privacy (see Section 4.3.4).They often felt to be considered a deterrent or the "enemy" by developers since they were viewed as responsible for blocking the development process.This obstacle could make it challenging to establish a Personal Common Ground, consequently affecting future communication.However, privacy experts also wished for a clear communication process and direct communication with software developers instead of referring them to privacy requirements.By contrast, developers mentioned that they struggled to understand privacy requirements and considered them ambiguous and not detailed enough (see Section 4.3.4).Perception also depended on how the organizational structure and communication process were designed.Often team coordinators (e.g., product owners or technical team leads) were the pivot point for transforming higher-level requirements into technical requirements and breaking them down into work packages.But even if the communication between the privacy experts and a team coordinator is bridged, technical decisions still need to be made on handling the privacy requirement.Consequently, the development team needed to be involved.
With this, we argue that the development teams' perception is strongly influenced by the fact that (i) the technical detail of the requirements is often insufficient from the teams' point of view and (ii) privacy requirements do often lack a "visible" value.Developer participants complained that the privacy requirements they received did not specify how to be achieved, so they had to figure out their implementation by themselves.Thus, requirements should specify why they are relevant in the context, concrete steps that need to be taken by the development teams and the desired outcome.As privacy experts may lack the technical knowledge to create requirements that are detailed enough to cover edge cases present in the system, development teams need to be able to contact the experts with questions and requests for clarifications to ensure correct implementation.

Recommendations for Industry
Our privacy expert participants did not have expertise in verifying privacy requirements on a technical level.Checking the source code is rather a rare procedure.Similar to processes adapted in the security field, such as regular penetration tests [100], privacy should be part of all stages in the software development process.However, performing penetration tests is not enough for a sustainable change towards more security within the product teams [65].Therefore, promising tools were introduced in the security field that can be integrated within the software development build pipeline (e.g., static analysis, dependency checking) [27,66,77,90].It seems the privacy field is still lacking the usage of similar tools within the company context.While the OWASP community aims to make security accessible and understandable for everyone, our developer or team coordinator participants did not refer to a similar guide concerning privacy.Similar privacy-focused best practices accessible to software developers might further improve privacy implementation.
Educate development teams early about privacy concepts.We encourage businesses to educate their development teams on privacy concepts, which is crucial to ensure an early adoption in the development process.This may further help to establish a more accurate Communal Common Ground, making communication easier.Implementing privacy requirements late in the development process due to companies' constraints such as limited project resources (see Section 4.5) will most likely incur higher cost.Thus, allocating the resources to educating development teams about privacy concepts early in the development process is very likely more efficient.For example, adopting concepts like data minimization reduces effort if implemented early in the development process.Fixing a product late in the software development cycle may require substantial re-writing and redesigning to ensure the product will still function correctly with fewer data.Thus, development time and funding can be saved by taking care of issues early.However, developers need to be supported during this step, as they may feel restricted by the requirements (see Section 4.2.3).Within our study, developers were accountable for verifying implemented privacy requirements.However, as most were confused about privacy and security and did not know common privacy concepts, we highly recommend establishing a baseline of knowledge for the development teams by going beyond presenting them with privacy requirements on a oneway communication line.Teaching privacy concepts to software developers might have multiple advantages for companies, as it may help the development teams to (i) fulfill requirement concepts from different domains (e.g., through data minimization), (ii) gain awareness of privacy and privacy risks, and (iii) might close the communication and language gap between privacy experts and the development team.
Build a privacy-supporting company environment.Our study showed that developers consider privacy experts as disruptive fostering an adversarial relationship between software engineers and privacy experts, resulting in a negative privacy attitude.Thus, it makes it less likely that developers will actively approach privacy experts or pay more attention to identified privacy issues.Consequently, bad habits and routines might be established, which are resource-intensive to correct, as already learned from numerous attempts to change behavior in the security domain [38,42,65,91,99].Limited interaction will further obstruct the creation of Personal Common Ground between the two groups, making communication more difficult.We call for the support of privacy experts, as technical expertise cannot always be expected.Technical experts are required to explain the system, as well as verification of the implemented privacy requirements.Consulting privacy experts in one direction (artifacts only) will not ensure the correct implementation of privacy requirements.

Recommendations for Academia
This study is the first step in offering insights into a highly complex communication problem.Based on the resulting theory, we suggest the following research objectives for future work: Verification of privacy requirements.Verification of privacy requirement implementation is often missing and threatens users' privacy.More research is required on how the verification process could be improved for developers on the technical side and privacy experts on the legislation side.
Privacy champion.While security champions were explored in research [35,37,91], it is unclear yet who is considered taking responsibility and acting as a privacy champion [82], developers, team coordinators, or privacy experts?Team coordinators were often tasked with the fulfillment of privacy requirements.Having employees with experience or certifications regarding privacy in leadership positions might be a good way to embed privacy principles.These employees could have the role of supporting developers but also understand the reasoning and importance of the requirements provided by the privacy experts.Further, they could provide technical details to the privacy experts involved in creating guidelines and requirements.
Differentiating security and privacy.Many developers and team coordinators seemed to think of the same issues concerning privacy and security.Thus, participants often focused on possible scenarios with attackers but ignored the potential incorrect collection or misuse of personal data.Further research is needed on how developers can be supported with better-differentiating privacy and security issue implementation.One possible direction might be exploring privacy education in Computer Science (CS).Education can play a crucial role in implementing security and privacy requirements and should start early, e.g., in the university context.It might help to establish a more accurate Communal Common Ground by improving developers' understanding of privacy.Recommendations have been issued for the security education of computer science students [81,83,101], suggesting early education improves the students' security mindsets and mental models.Introducing software developers to privacy and legal concepts in the context of software development early in their studies might sensitize future software developers to potential privacy threats.With many CS curricula showing little focus on privacy, educating CS students on privacyrelevant topics might be a good starting point to sensitize future developers to privacy issues [88].Future research should explore the role of privacy education.In particular, it would be interesting to learn where software developers gather their information when implementing privacy requirements and which sources they base their decisions on.
Developer-friendly privacy requirements.Participants often expressed issues translating requirements or expert feedback into clear tasks to fulfill certain privacy requirements.For creating privacy requirements, it might be necessary to consult not only privacy experts but also software developers tasked with fulfilling them.More research is needed in requirements describing the desired outcome and concrete implementation steps the development teams have to take.Further privacy requirement tasks might be explored in future work (e.g., right of access, right to erasure).Participants also mentioned that they faced issues processing data across international borders (e.g., processing EU citizens' data in the United States) and difficulties implementing data retention policies.
Fostering a healthy relationship between privacy experts and developers.Different parties with different backgrounds perceive each other in a blocking manner has also been found in security research (e.g., [9,13,35,91]), such as end users seeing security experts and the measures they deploy within their company as a hindrance, resulting in a dysfunctional relationship between the two groups [51].This may limit the interaction of the groups, hindering the establishment of a Personal Common Ground.With this work, we advocate against fostering an adversarial relationship between privacy experts and developers, as already observed in the security field [34].To combat these issues, involving experts early in the software development process, as learned in the security field exploring the communication of staff and security experts [9], might be a good starting point for future privacy research.

CONCLUSION
Despite measures to improve user data protection (e.g., GDPR/CCPA), data breaches threaten user data worldwide on a daily basis.Understanding the creation, communication, and implementation process of privacy requirements is the first step to improving user data privacy sustainability.Compared to previous work acknowledging developers are struggling with privacy tasks, we focused on the privacy requirement implementation process within a company context concerning relevant roles involved.
In this study, we conducted 30 interviews with privacy experts, software developers, and team coordinators using a grounded theory approach.We analyzed the different understanding of privacy concepts and how team coordinators, software developers, and privacy experts perceived the communication.Additionally, we explored how privacy requirements were created, forwarded, and implemented.We contribute a theory grounded in our participants' data, suggesting a communication gap between software developers and privacy experts.Further, we highlight common obstacles in the communication between privacy experts and developers, discuss how to address them and provide recommendations on embedding privacy requirements into the software development process.
This study presents a first qualitative look at the communication gap of privacy requirements as a research problem.Future work should examine different types of developers.Additionally, to explore the generalizability of the findings, the sample size needs to be increased to gather quantitative data.
(5) Communication of privacy requirements (Team Coordinators) • Which tasks are you involved in the privacy process?
• Who provides the information required to successfully implement privacy requirements?• What information about the software project do you pass to privacy experts?• When do you get privacy requirements for the project?
• How are privacy requirements created?
• Do you need to consider any privacy regulations or guidelines within your company when developing software?Please elaborate.• Do you understand these privacy regulations or guidelines?
• Which format do the privacy requirements have that you get (e.g., check- lists, templates)?• Is essential information missing which helps to implement privacy require- ments?• What does the communication process look like between privacy experts and team leads?• What does the communication process look like between software devel- opers and team leads?• Who involves you in the privacy process?
• What person would you contact to get privacy requirements?
• How are the privacy requirements passed to the development teams/management?• Do software developers understand the provided privacy requirements?
• How do software developers implement privacy requirements in the software development process?• Do software developers face any issues implementing privacy require- ments?• What would the communication process look like if developers have questions regarding privacy requirements?• Do software developers get feedback on the implementation of the privacy requirements?By whom?• Would you check the software code for privacy requirement issues?
• What do you like about the communication process between privacy experts and software developers within your company?• What might improve the communication process between privacy experts and software developers within your company?• Is there anything related to privacy requirements at your company you would like to talk about?(6) Example walkthroughs (All participants) • Can you provide a concrete example of a privacy requirement you have created at work? • What was the reason for creating the privacy requirements?Was it reacting to a change in the legislature?• For what context were the privacy requirements created?
• Who received the privacy requirements?Now I would like to discuss fictional scenarios with you.You are given the following requirement from your legal department: "The access control must be enabled for the following table: Table_1b" -(Developer, Team Coordinators) • Is this a privacy requirement that could be implemented within your company?• What would the communication process between privacy experts and software developers look like for this privacy requirement?• How would software developers implement this privacy requirement?
• How would the implementation of this privacy requirement be verified?You are given the following requirement from your legal department: "User data stored in the following tables will be retained for a maximum of 30 days after collection: table_1, table_2, table_3" -(Developer, Team Coordinators) • Is this a privacy requirement that could be implemented within your company?• What would the communication process between privacy experts and software developers look like for this privacy requirement?• How would software developers implement this privacy requirement?
• How would the implementation of this privacy requirement be verified?You are given the following requirement from your legal department: "The team's use of model output data will be limited to analytic purposes related to X measurement experiment.Collected data cannot be used for advertising" -(Developer) • Is this a privacy requirement that could be implemented within your company?• What would the communication process between privacy experts and software developers look like for this privacy requirement?• How would software developers implement this privacy requirement?
• How would the implementation of this privacy requirement be verified?Your company makes the following commitment, and you are tasked to communicate the corresponding privacy requirement to the software developers: "Anyone who wants to run housing, employment or credit ads will no longer be allowed to target by age, gender or zip code." -(Experts) • Is this a privacy requirement that could be implemented within your company?• What would the communication process between privacy experts and software developers look like for this privacy requirement?• How would software developers implement this privacy requirement?
• How would the implementation of this privacy requirement be verified?Your company makes the following commitment, and you are tasked to communicate the corresponding privacy requirement to the software developers: "We do not access the microphone just because the app is open, nor do we use it when you are not in the app." -(Experts, Team Coordinators) • Is this a privacy requirement that could be implemented within your company?• What would the communication process between privacy experts and software developers look like for this privacy requirement?• How would software developers implement this privacy requirement?
• How would the implementation of this privacy requirement be verified?

Motivation for implementing privacy
Statements that clarify the reason participants have for implementing privacy requirements into the software.This can be, for example, personal motivation, wishes from customers, or trying to be compliant with legislation.
Maybe it's important because sometimes our clients contact us not because they want to ensure the privacy compliance of their product, but they are required to do so, for example, by a marketplace or [...] they want to be certified or they want to get a big client, for example, some software development team that offers software for banks.
Compliance (22/15) And other than that, it's very difficult because startups do not have that much budget to look into these concepts, to hire a particular expert.And in fact, most of the startups, they do not have a privacy person, so they do not have a security person as well. Privacy

Figure 1 :
Figure 1: Communication pattern between privacy experts and development teams.

Figure 2
Figure2summarizes the obstacles supporting our theory and guidance on combating them in promoting a common ground.

Table 2 :
Participants' job title Practices.Seven privacy expert participants noted that having a clear process and open communication would be helpful for a good working relationship with the development team (e.g., E2, E6, E8, E9, E10).One key factor mentioned for good practice was involving privacy experts early in the software development process: "I think it's more of where we [privacy experts] are on the planning stage, and we have provided you [project manager] with a requirement.So it's just up to them [software developers] to implement what we have recommended." (E8)

Table 3 :
Codebook (continued)And since we use GCP like the Google Cloud platform, it's actually quite easy to set these limits because when you add it, you just need to well, you can for a table itself, you can give a limit for how long Items can stay in that table and then it's all just kind of automated.
I think that we can start the communication at an early stage of the process because sometimes they come to us when they have already worked on something.For example, the recording marketing solution was quite already in place and finally, we had to say, no, you cannot do this because we are not able to treat this kind of data too much.Company contextStatements concerning factors perceived as positive by participants within a company context.Examples are experienced colleagues, awareness, and training.I think one of them comes from a privacy background, from a large, kind of data company in the US.And so I think that experience helps a lot because I think they go within the engineering squad, they go to that particular individual.Training (23/11), Awareness (17/11), Experienced Colleagues (17/12), Company Culture (8/5), Experience (5/5), Resources for Privacy (3/2), Third Party Responsible For Privacy (3/3), Collaboration (2/2), Internal Audits (2/2) Implementation Statements relating to helpful factors during the implementation of privacy requirements.Examples are good tools, good examples, and regular testing.It's again, it comes to, like I said, with GDPR, the person who did it first is going to struggle.But as long as there is a precedent, the ones that come after that, it's much easier for them.Technical information I feel is always missing.The client more often than not doesn't know.You know what?Technical requirements are being implemented.You know, and for some reason, I find that they either don't wish to know or they're happy to just put a very general paragraph to do with that or they don't ask.Legal Terms Unclear (15/11), Lack of Communication (12/9), Privacy seen as Disruptive (12/8), Missing Information (7/7), Privacy Expert not Technical (7/5), Communication is Hard (5/4), Late Requirements (5/3), Expert not Reachable (4/2), Number of Regulations (3/3), Missing Resources (2/2), Changing Requirements (1/1) Company context Statements related to issues that arise from the company context.Examples include a lack of responsibilities, resource problems, and data use by different departments.
not Priority (29/14), Resource Problem (11/7), Third Parties (11/9), Regional Differences (10/6), Human Error (8/7), Lack of Responsibility (8/7), Lack of Teamwork (8/3), Data used by Different Department (7/5) So there are a lot of scenarios that are not directly covered inside the explaining regulation, and that's where the back and forth with the regulating body comes because you need to give them examples.What if this, what if that, will that be compliant to you?