A Narrative Review of Factors Affecting the Implementation of Privacy and Security Practices in Software Development

The reviewed studies discussed the regulatory bodies concerned with privacy violations in software development, among which three were the most prominent: government, platform authorities, and authorities enforcing industry standards.

Government policies represent the federal, state, local, and industry-specific laws and regulations (e.g., HIPAA, COPPA, FERPA) protecting consumer privacy and security. These regulations are often unclear and confusing, making it difficult to comply with them [12, 31, 100, 108], or lagging behind the rapid evolution of technology [26], and quickly becoming outdated [22, 26]. Some even raised concerns about governmental sovereignty over corporations in regulating privacy that can be entangled with national interests, such as when governments force companies to provide them with access to user data through so-called “backdoors” [16]. Moreover, data protection laws and regulations often prescribe vague directions that require substantial input from human judgment and expertise to interpret the implications in practice [13, 31]. For software companies operating in multiple countries, it is especially hard to comply with the variety of potentially contradictory regulatory requirements of different markets. Finally, the use of cloud services has major privacy implications and raises additional regional legal challenges, such as those dependent on where users’ data is physically stored.

Development platform policies, such as Google Play Store, Apple’s App Store, Amazon Web Services, Microsoft Store Policies, and Code of Conduct offer developer policies and guidelines outlining requirements for systems. Some recommendations play an advisory role, suggesting the best but optional practices, whereas others are mandatory—their implementation is reviewed and is necessary for approval by the platforms. Development platform policies help to inform developers about security standards and encourage them to adopt secure coding practices [22], and provide a certain degree of data privacy by imposing privacy requirements [51]. However, these guidelines can be seen as inefficient, because different platforms may not be aligned in terms of definitions of privacy-related terms [81] and promote diverging or even conflicting values [100, 105]. The general challenges of cross-platform development can be further exacerbated by different platforms requiring developers to comply with different responsibilities for data protection and privacy disclosures. Better alignment across platform policies, potentially enforced by regulations, will reduce the overhead of developing software for a variety of different platforms, and eventually improve the adoption of best practices for privacy and security.

Industry standards attempt to self-regulate the privacy and security practices in a specific industry and represent the set of privacy and security requirements that are generally accepted and followed by most members of a particular industry. Industry privacy and security standards such as the Payment Card Industry Data Security Standards (PCI DSS) and ISO/IEC [68, 82] offer privacy and security guidance to software companies. These standards often focus on requirements around what privacy and security outcomes software companies need to achieve, without adequate guidance on how to best achieve these goals. Having a clear set of widely agreed upon best practices, standards, and processes for implementing them would positively affect developers’ adoption of best practices for privacy and security.

Developers’ perceptions about norms prevalent in society or certain cultures affect their propensity to deploy security and privacy principles in the product design and development process [16, 57, 60]. Prior works agree that different perceptions of privacy or different needs based on individual preferences can lead to diverse types of concerns about privacy [13] and various expectations about usability, security, and privacy [22]. To account for variability in social norms, researchers highlight the importance of involving broader societal groups into the discourse and enforcement of privacy norms and regulations [12].

Market competition and company reputation could either motivate organizations to implement privacy and security engineering or diminish its priority. For instance, strong competition might push organizations toward aggressive business models (e.g., focusing on personal data monetization or invasive data-driven targeting approaches) and diminish ethical practices in the race for the market share [111]. However, companies with a large market share may be less concerned about the loss of some customers due to a data breach incident than companies operating in a highly competitive environment, where a publicized data breach scandal can create a wave of customer switching, significantly affecting the business [60]. Such reputation risks encourage companies to pay more attention to security [7].

The maturity of an organisation (not solely determined by age) plays a role in prioritizing security and privacy practices within it, and can be correlated with other factors in our model. For instance, leaders of startups may initially be very focused on fundraising and growth—the existential needs of a new business—and as their products mature, they may start giving more consideration to privacy matters [26, 100]. Expansion to international markets requires compliance with international privacy regulations [100], increasing the relevance of the environmental factors discussed earlier (Section 3.1.1).

A lack of resources is detrimental to the adoption of privacy and security practices [12, 108]. Conversely, the availability of sufficient human resources who could take on the job of ensuring security and privacy practices is an important factor for their adoption [7]. Some companies prefer to have an expert specialized in security rather than to try to educate the whole team about it [132].

The portion of company’s financial resources allocated to the privacy and security budget, specifically, plays an important role in the adoption of privacy and security practices in the development process [7, 14, 47, 53, 70, 94, 137]. For instance, introducing security tools can take a substantial cut of a company budget [70, 132] but also result in indirect costs such as developers’ time [11, 132]. Professional security training [14, 53, 70, 94, 137] and security certification (e.g., ISO) are often seen as too costly to implement in terms of time and resources while their value is questioned by many companies [60, 74]. Moreover, security risks are often underestimated in relation to the investment required to protect against them [112].

Privacy and security culture represent shared perceptions, beliefs, and social norms surrounding privacy and security [57, 132], the commitment to address concerns, and promote a privacy and security mindset [60]. Privacy and security culture plays an informal role in affecting organizational privacy conduct [6, 8, 122], encouraging and supporting security practices [7, 60, 70, 132], the development process [70], and developers’ choices regarding security [60]. As engineers do not make independent decisions about system design and their work is situated in a certain context [16], previous research recognizes the strong effect of an organization’s privacy norms on developers’ privacy design behavior, conditional on engineers’ motivation to comply with them [112]. Inefficient organizational norms and practices can put developers under the impression that privacy is not an important value in the organization, with negative consequences [57].

Senior management privacy and security awareness and support have a strong influence on the implementation of security and privacy practices [47, 64, 70, 74]. Prior research recognizes management’s responsibilities in supporting security and privacy culture both at the top level [49, 63, 69, 70] and through internal team supervision [57], by providing adequate resources for security implementation and communicating their expectations clearly [49, 64, 70], or mediating the communications between various interest groups to resolve related conflicts [63]. The lack of understanding of the security practices and their importance in the development process [70] may result in deferring security [7].

Providing developers with incentives (rewards and sanctions) can impact their privacy and security practices [70]. For example, in a recent qualitative analysis of developers’ comments on Reddit, it was found that they perceive little additional benefit from the substantial amount of additional effort required for compliance with Google Play privacy and security requirements [80]. Rewards can include monetary incentives [7, 59], feedback and empowerment [22, 57, 59, 117], and recognizing the value of employee work [59, 117]. The lack of incentives can encourage developers to prioritize functionality over security/privacy [22]. However, encouraging developers’ intrinsic motivation has been recognized as a more efficient strategy than extrinsic, especially financial, rewards [7, 59, 109, 117].

As sanctions, developers can be penalized for failures to comply with security standards [22, 64, 109]. The certainty of detection has a stronger influence on security behaviors than the severity of penalty [64]. The combination of preventive methods for privacy protection and punitive mechanisms (e.g., reporting violations to authorities) can act as an efficient strategy to discourage developers from risky behaviors [13]. Instead of introducing sanctions, some researchers suggest that companies should encourage developers to report errors and ensure fair investigation [32].

The knowledge that organizations circulate in the form of training, educational courses and materials, peer and privacy/security champion support, and so on has also been shown to influence the security and privacy practices of the developers.

Privacy/security education and training presumes the exposure of company employees to privacy and security knowledge resources that help developers understand the potential impact of privacy and security problems on the organization at large [8, 99, 132]. Application of a situated learning framework, where knowledge transfer happens directly within a development team, has been found to be more effective in incorporating such knowledge into practice than theory-oriented learning curricula [122]. Privacy/security training is considered valuable not only for the developers [22, 70, 99] and security advocates [59], but for all stakeholders involved in the software development process [70], as they ensure the support of security initiatives as an integral part of the organization [30]. Yet, security training rarely teaches developers to use security tools [60, 70, 98, 132] and ignores “soft skills,” such as communication, collaboration, presentation, and writing [58].

Peer Support . User studies with developers identify peer support as a key resource in judging the ethics of their decisions about privacy [112], and encouraging them to discover new security tools [103], and adopt security best practices [15, 22, 132]. Developers seek peer advice from privacy/security specialists, current and former colleagues, friends, and other developers, such as from forums, meetups, or work-related groups [11]. Yet, guidance by others’ examples can also be counterproductive, as it may not address important topics and may include outdated advice [3].

The Role of Privacy/Security Champions . Instead of trying to educate each employee about privacy and security, some research recognizes the value of privacy and security champions who act as experts or enthusiasts “leading by example” [60], gradually shifting the privacy/security culture in a positive direction [17, 117, 122], and even taking part in the development of effective organizational security policies for employees [15]. In contrast to regular peer support, champions take on a proactive role in promoting privacy and security values in the organizations.

Q&A and Code Sharing Websites . Q&A (questions and answers) and code sharing websites, such as Stack Overflow or GitHub [2, 11, 77, 79, 118, 132], provide developers with technical support and privacy and security related knowledge, which might not be available within the company [11], and presented in a more comprehensible and less formal fashion than official documentation [79], such as code examples or examples of how an API works in a particular context (in contrast to a general API documentation) [79]. Despite their usefulness, relying on these resources, even when high-scoring answers are provided by the highly ranked peers [132], can lead to less secure solutions [2, 42, 90], proliferating vulnerabilities [22], and ignoring the rationale behind the provided recommendations [77, 79].

Media and Other Resources . Mass and social media, as well as blogs, are increasingly used as the channels of privacy and security knowledge dissemination [58, 132]. The content of such channels can be more engaging than formal documentation due to the use of images, metaphors, or pop culture references [58]. The exchange of moral and cautionary tales, news, or stories about legal repercussions and other consequences for developers help developers justify privacy values, and rationalize their technical and instrumental realizations of privacy [105].

The structure of development teams varies in the degree of specialization from narrow-focused specialized units (that might not communicate with other departments) to teams with wide domain diversity.

Siloed Teams . Privacy and security practices could be improved through the collaboration of software development and design teams with legal [16] or business departments [12, 43, 49, 54]. However, such collaborations can face challenges, as lawyers and developers often “don’t speak each other’s language”—that is, don’t share the vocabulary and conceptual frameworks of privacy [16]. Such communication issues often result in siloed teams, leading to a variety of problems at different levels. For instance, privacy professionals might be locked in legal compliance departments, hindering the access of the development teams to their expertise [12]. In contrast, privacy professionals in “engineer-only design teams” might not have an opportunity to raise and address privacy issues during the design process [126]. Bureaucratic barriers can further hinder the institutionalization and spread of privacy norms within the organization [100, 126]. Even when developers have access to relevant experts, they may choose not to consult them due to the shortage of time and communications overhead it would require [55]. To resolve the communication issues between different departments, privacy experts and teams may be called on to mediate the interests of different stakeholders, balancing the external and internal privacy requirements and practices [12, 112].

Team Diversity . The lack of demographic and background diversity limits engineers’ perspectives and increases the likelihood of discriminatory implicit biases around privacy and security [100, 126]. Increasing team diversity [58, 70, 126] by involving security experts and employees responsible for facilitating cross-departmental connections could narrow the proficiency gaps [58] and help establish trust and shared knowledge among team members [126], leading to more successful self-management of teams [43] and a greater sense of belonging and collaboration [59].

These include organizational policies and guidelines that recommend certain practices and tools, aiming at ensuring privacy and security in software products. For such documentation to be effective, it not only needs to be available in the organization, but developers also need to be aware of it and perceive it as useful.

Availability . The existence or even enforcement of certain policies and procedures to address software security and data privacy [7, 70, 103, 109] is necessary for the implementation of secure software development [9, 32, 70] and privacy engineering [101], especially in the companies with privacy as a core value or companies operating in privacy-sensitive domains, such as healthcare and finance [57] (see Section 3.4.1). Although there is a wide variety of available security resources, companies might lack a formal plan or process for choosing, adapting, and integrating them in practice [55, 60, 82, 96, 124]. As a result, developers might lack suitable resources [22, 132]. Unlike security tools, privacy tools to assist software development are more scarce [11, 117], or address privacy through security mechanisms, such as secure data sharing [31].

Awareness . Although security and privacy procedures might be in place, developers may not be aware of them, or whether they are mandated to read, use, and comply with them [74]. Some studies report high awareness about internal procedures and policies among developers [7, 57, 112], whereas other studies suggest that developers are often unaware of privacy recommendations [26], privacy threat models, mitigation strategies, less privacy invasive coding alternatives [79], privacy-specific tools and checklists [11, 126], and code analysis and testing tools [6]. Developers also have little knowledge regarding privacy and security regulations [11], security tools [7] or secure development lifecycles [47], and concepts related to usable security [80].

Perceived Usefulness . In addition to developer awareness of existing documentation and policies, companies should ensure that developers perceive the security and privacy practices described in these policies as useful and feasible [15] and that the guidelines and documentation are comprehensive and easy to understand [79]. Developers are less likely to implement recommendations when they doubt their effectiveness and usefulness [47, 74]. For instance, some developers find privacy recommendations provided by the Federal Trade Commission (FTC) outdated, irrelevant, too generic, and, therefore, not useful [26]. Another widely used tool, Data Protection Impact Assessment (DPIA), may not match the system architecture and thus be perceived as obsolete, outdated, or even incorrect [107]. Developers also believe that certain privacy mechanisms can be easily broken, overridden, overruled, or de-anonymized [16], whereas the guidelines for implementing such mechanisms are complex and too theoretical to be used in practice [103]. Some third-party privacy tools even raise concerns, as they might collect information that developers are unaware of [11]. Security code analysis tools might be considered not very useful due to their complexity [7] or due to time resources they require to implement [132]. Academic resources on security might become outdated as well and are often perceived as distant from real-world challenges [60]. The value of security certification may be doubted due to its costs exceeding the perceived value [74]. Security certification might even be perceived as counterproductive: it can discourage product updates, as the company needs to apply and pay for the certification after it is voided following every software update [60]. Some developers do not trust existing standards, for instance, due to evidence of government intentions to purposefully weaken cryptographic protections [52].

Software entrepreneurs tend to underestimate the role of privacy at the initial stages of business development [6, 26], despite prior research agreeing that it is important [31]. Developers generally more easily agree that they should consider security from the earliest planning phases rather than privacy [7, 29, 85]. Auditing the security of the code only before the code integration or its release can pose significant security risks [22, 132]. The failure to consider privacy and security from the early stages of software development is associated with the difficulties with defining privacy and security as concepts and requirements, and with the tensions between privacy/security and other technical/system requirements.

Difficulties with Defining Privacy and Security Concepts and Requirements . Development teams are usually familiar with the concept of software security requirements; however, the concept of privacy in software development is considered to be rather abstract and vague [13, 16, 22, 76, 103, 108, 110, 112] and context dependent [16], thus difficult to implement. Since, conceptually and methodologically, privacy is often confounded with security [110], developers sometimes use the data security vocabulary to approach privacy, which limits their consideration of privacy [57], or even sacrifice privacy for security [7, 31]. This is particularly concerning, because improving security does not always imply improving privacy (as in case of confidentiality), and can even have the opposite effect. Difficulties with conceptualizations, complexity, constant evolution, and context dependency also translate into difficulties with defining privacy [13, 31, 89, 91, 110] and security requirements [70].

Tension Between Privacy/Security and Other Technical and System Requirements . Generally, data protection requirements are considered as non-functional and might not fit into standard software development practices [73]. Security [7, 31, 82] and privacy can interfere with other requirements, such as functional requirements, integrity requirements, performance, and usability [6, 13, 16, 22, 55, 60, 79, 91, 103, 108, 126]. For instance, the collection and use of end user data for the optimization of services and design might compromise data protection agreements [54], a nuanced user authentication process (e.g., two-factor authentication) requires additional user effort [22, 51], and developers often find it hard to obtain a meaningful informed user consent using existing mechanisms [11, 16, 54, 73, 114]. However, ignoring the privacy needs of users can negatively impact their trust and loyalty to a product or a service [31]. Thus, developers face the challenge of balancing security and usability [15, 19, 62]. Although the involvement of users in the design process via user studies and reconciling their sometimes conflicting preferences for privacy, security, and usability is not easy [31, 55], the benefits of such user-centered approaches are undeniable [31, 60, 100].

Complex and more nuanced requirements might be traded for simplification of the development process. For instance, developers might request just one permission on the multiple data items from users, which will lead to excessive data collection [79] violating data minimization principles [66]. To prevent privacy risks, previous studies recommend incorporation of privacy considerations into the definition of software requirements and specifications [16], which might require improving general software requirements that are often not sufficiently maintained and managed [57].

Privacy and security requirements might be in place, but developers still might not consider them during the implementation stage. The reasons vary: it is not easy to operationalize them or prioritize privacy and security over time pressure, or due to usability issues with the privacy/ security engineering tools.

Difficulties with Translating Requirements into Practice . A large number of studies recognize that it is difficult for developers to translate privacy [16, 31, 38, 73, 100, 103, 135] and security [22, 60, 134] requirements into specific software development processes. Partially, it is related to the underlying difficulties with defining privacy concepts (see Section 3.3.2) and lack of knowledge (see Section 3.5.2), as well as with technical challenges, such as identification of sensitive information [135], technical complexity of the system (e.g., in a cloud environment) [23], and technical implementation of data anonymization [31, 73], data minimization [103], and encryption [73, 135], especially if organizations fail to provide developers with the methods and resources necessary for supporting the implementation of privacy and security requirements [110]. Developers might also direct their attention to the formal procedures and fail to implement a distributed privacy architecture [12] or implement privacy methods in isolation, via different stakeholders that have different levels of knowledge of the system [107]. Certain development approaches, such as Agile and DevOps, might require ad hoc solutions to address security requirements [23, 31], due to the privacy risks posed by the modularity of these approaches and concentration of user data “in the hands of specialized service providers” [54]. To address it, similarly to waterfall development methodologies [102], organizations might include privacy and security practices in every phase of the development process [70, 73]. The need to comply with the variety of potentially contradictory requirements, such as if an app is networked to communicate with multiple fragmented services, introduces further complexity in searching, reading, and reconciling differences in the documentation and requirements of each of those services [119].

Tension with Time Priorities . Limited time, especially in the conditions of time-to-market competition pressure [22, 60], can become an impediment for data protection implementation [11, 112, 124] and for improvements in the usability of privacy and security features [55]. Privacy is usually not a priority task that developers are ready to allocate time and resources to [10, 96, 110, 126]. Some engineers believe that implementing privacy features can slow down the development process [16, 74]. Similarly, security is pushed down the priority list in the conditions of tight deadlines in which most software companies have to operate [47, 70, 72, 94, 112, 132, 134]. Although keeping the overall development time within adequate limits is important [70], the shortage of time dedicated to security can ultimately result in a technical debt with later security issues leading to increased costs, system fragility, and reduced rates of innovation [54].

Usability Issues of Privacy/Security Tools . Usability of privacy and security tools is important [70, 95, 131]. Issues with usability, steep learning curves, and limited library support reduce the adoption of such tools by developers [7, 27, 44, 79, 128]. Poor default configurations in tools and libraries, confusing security APIs, and insufficient documentation lead to errors in their usage [22, 39, 41, 48, 73] and in developers’ correct disclosure of libraries’ data practices [81]. The lack of interoperability of cryptographic libraries on multiple platforms also impedes collaboration between teams and oversight of a security architect [60].

The review and evaluation stage involves an assessment of whether and how the initial requirements are implemented in the system [73]. In this stage, issues with the evaluation process and metrics may arise.

Evaluation Process and Metrics. Privacy assessment mechanisms recommended and used by the legal enforcement authorities are limited to a narrow set of privacy mechanisms, and lack guidance on how to technically implement them [12, 16]. Although app marketplaces provide certain assurance seals based on the app review process [105] and automated compliance checks are used to verify the compliance with privacy regulations [16], clear and objective criteria and metrics for assessing success in addressing privacy issues are still largely lacking [31, 103, 117]. As Assal and Chiasson [6], Votipka et al. [125] indicate in their research, developers admit limited testing for privacy and security risks. As systems often change, introduce, and remove features [54], it is challenging to keep the security standards (e.g., for cryptographic products) [60] and privacy assessments up-to-date, creating a need for continuous privacy management and monitoring [110]. The lack of automated tools for privacy and security assessment makes developers rely mainly on their own expertise [23], increasing the amount of time required for assessment, and the probability of human error. However, manual code reviews may improve developers’ understanding of underlying data processes [117]; in conjunction with security tools, manual code reviews lead to the best results [132].

Companies’ beliefs about whether their products are an interesting target for security attacks influences their eagerness to address privacy and security concerns [7]. For instance, developers working on B2B products [26, 60] or internal applications [132] do not feel the need to deploy strong security safeguards. In contrast, a large or growing user base is believed to make a product an attractive target for attack and invokes developers’ concerns about data security [100, 132]. High perceived sensitivity of the data or context in which it is collected (e.g., finance, health, child- or education-related contexts, especially if they are subject to special regulation [11, 31, 93]) also leads to a higher degree of privacy and security concerns among developers [13, 22, 26, 31, 57]. Conversely, products not collecting personally identifiable information lead developers to demote the importance of privacy and security in product design [11].

The tension between privacy and primary business priorities focused on revenue maximization often hinders the implementation of privacy-preserving features in software products [57, 74, 101], especially when data-driven business models rely on the monetization of personal information as a source of revenue [54, 112] and in early-stage startups [26]. Time and budget spent on privacy engineering is believed to be better invested in innovation, development, and growth [55, 112].

Security and privacy centric features can help organizations to distinguish their products in the marketplace [13, 31, 51, 54, 60, 61, 67, 70, 105, 112]. For instance, in a “crowded” software market such as Android apps, privacy features can be used to differentiate products from competitors [105]. Greater competitiveness can also be achieved by efficient privacy management [13, 26] and providing users with support and transparency regarding their data [51, 100]. Engaging in privacy research further helps companies understand and better address user needs and preferences, consequently improving the product overall [31]. However, some developers fail to recognize the competitive advantages of embedding privacy in products or obtaining privacy and security certification [74], due to the lack of awareness regarding the benefits and risks associated with user data privacy and security practices [110].

Hierarchical position and role, perceived personal responsibility, and autonomy and control over privacy and security decisions have been found to affect their implementation.

With respect to hierarchical position, engineers in senior or managerial positions tend to have more responsibility and control over privacy and security engineering compared to employees in more junior roles [112]. Previous studies identify that such division can lead to negative consequences. For instance, limited involvement of non-senior level employees in high-level firm decision making can lead to poor adoption of privacy principles in the development process [12]. Besides, those in managing roles can lack substantive expertise to make privacy decisions [108].

Perceived personal responsibility of developers and engineers does not always depend on professional position or role [74, 112]. Prior research often reports the lack of perceived responsibility of the developers and engineers in implementing and enforcing security and privacy, or limiting of perceived responsibilities to, for instance, only minimizing data usage [79, 90]. Specifically, “not my problem” mentality [98], lack of “moral responsibility,” and absence of privacy and security requirements among deliverables [16, 76] in a job description [7] or formal responsibilities [6, 57] often lead developers to neglect security and privacy engineering [112]. Absence of personal responsibility can be also caused by the developers’ misconception that their mistakes are unlikely to cause security vulnerabilities in the system [70]. Some developers believe that users themselves are supposed to protect their personal data [16, 51, 96, 112, 115]. Even when the primary responsibilities directly related to privacy and security engineering and coding are clearly defined, it may be hard to define, especially in small organizations, responsibilities for secondary tasks, such as user interface design of privacy features, audits, privacy policy updates, or privacy nutrition label assignment [119]. In the absence of specialized experts, these tasks may be assigned to the developers [55], who may not have sufficient expertise to perform these tasks, leading to subpar quality of implementation.

A general lack of a clear distribution of privacy and security roles and responsibilities in many organizations or teams presents another challenge [20, 74, 96, 110]. In some cases, such roles are substituted with collective responsibility [16, 26, 76], reducing a more systematic privacy engineering approach to ad hoc decisions that lack enforcement [31]. On the one hand, in the presence of specialized privacy or security experts, the developers shift the responsibility over to them [11, 79, 100, 112, 132]. On the other hand, the lack of specialized experts could result in non-expert staff taking on part-time responsibilities for implementing security and privacy [74].

When developers perceive a lack of autonomy and control over decisions and implementation of privacy and security features [30, 109], they are less likely to take action to influence or execute such decisions in software design and more likely to rely on external advice about it [79]. The autonomy to act according to personal beliefs may also be overridden by the tendency to comply and conform with organizational decisions [104, 112].

The factors related to privacy and security expertise, knowledge, and skills of developers are commonly mentioned as predictors of implementation of privacy and security practices [6, 16, 55, 90, 112]. Important skills for implementing security practices include a wide range of expertise including technical security skills [58, 59], competence in assessing security risks [17, 125], efficiency in applying security tools [22], and the ability to deal with a great degree of technical and organizational complexity [56]. Even though developers might have the skills necessary to implement some security mechanisms, they do not always have security expertise [2, 22], as it often requires knowledge from different fields and interdisciplinary collaborations [55, 82, 96, 122]. Compared to security, developers might be less prepared to deal with privacy challenges [100] and may not have appropriate privacy expertise, characterized as the ability to incorporate information privacy mechanisms in practice [16]. Developers find it difficult to make decisions about appropriate levels of privacy and when in the software development process they should incorporate it [103], especially when there are no guidelines about what it means to implement privacy and how to balance it against business priorities [101]. The lack of formal training is particularly evident when it comes to privacy [106], and such discipline is much needed to train privacy experts [13, 33, 34, 75, 123]. The lack of sufficient knowledge and awareness to implement security and/or privacy often results in adoption of unreliable third-party services [11, 79, 112], introduction of security vulnerabilities during the development process [7, 14, 40, 60, 70], misunderstanding of potential privacy threats and corresponding coping strategies [79], and frustration over decision making about embedding privacy in the development process and making developers rely on their personal opinions rather than objective knowledge [103]. Even when the developers have appropriate privacy and security knowledge, keeping that knowledge up-to-date may not be always easy [6, 90].

Based on the Theory of Planned Behavior [4], instrumental privacy attitudes reflect developers’ opinions about the importance of information privacy [16, 112], which we extend to security attitudes as well. Such attitudes may be shaped by the developers’ background, including their multicultural environments [100], and their personal opinions and beliefs in relation to privacy [8, 16, 103]. Some developers perceive privacy practices as relevant and important [16, 112], and others as unimportant [103], for example, due to the lack of awareness [74] or motivation to protect privacy unless it is required [79]. Positive instrumental security attitudes are associated with the higher uptake of security tools [130] and act as a strong motivation for implementing security practices [7, 59]. Some developers do not recognize the value of the effort invested in software security [25]. Developers who doubt the feasibility of building secure systems may also doubt the importance of following the security practices and be less motivated to incorporate them [112], which illustrates the necessity to consistently motivate and support their confidence in the importance of protecting data security [70].

Experiential attitudes indicate developers’ spontaneous feelings and emotions about security and privacy practices that affect its adoption and implementation [16, 17]. Motivation to advocate for software security among developers is also characterized by their interest in the field and self-challenging with security tasks [7, 59]. Engineers working in industry find security engineering less unpleasant than privacy engineering [112].

The prior experience of developers in collecting and storing personal information affects their privacy and security practices [6, 8]. Experiencing a security issue can increase developers’ awareness of, concern about, and attention to security for a long time [7], or motivate them to use security tools [132].

Some personality traits are associated with the adoption of privacy and security practices as well. For instance, the locus of control, which captures “the beliefs of individuals about whether the outcomes of their actions are contingent on what they do or on the machinations of outside forces” [71, p. 4], is a positive predictor of the adoption of ethical engineering in general, and privacy and security engineering specifically [112]. Inquisitiveness may affect the adoption of security tools [129]. People with pronounced imagination and emotionality, low immoderation [45], high proactiveness and reactiveness [56], and good soft skills [59], such as communication and people skills, context awareness, and service orientation [58], are more likely to become successful security advocates. One study mentioned the religiousness can positively affect a developer’s ethical decision-making process and, consequently, privacy-related decisions [112].

To increase companies’ motivation to take privacy and security seriously, policy-makers, industry associations, and software platforms need to create and enforce regulations and requirements that oblige companies to protect users’ data, make those regulations and guidelines easy to understand and interpret, and include quantified metrics for measuring success in compliance with them (Section 3.1.1). Penalties for violations of users’ privacy and security would further impact product-related factors, such as tension between privacy/security and business priorities (Section 3.4.2). This will make it more costly for organizations to ignore privacy and security aspects of the products and services they create, and encourage the inclusion of the potential costs of violations into the profit calculus, thereby moving privacy and security objectives up in the list of business priorities. Providing rewards for better privacy practices is another way to improve incentive structures (Section 3.2.5). For example, app marketplaces can offer better search rankings, special app featuring options, and privacy/security badges to those apps with better privacy and security practices. User-facing certificates and badges can be offered outside of the app ecosystem as well, to signal positive privacy/security practices to users, as a way to differentiate from competitors.

The demonstration of evidence that privacy and security of software are enforced can be a valid competitive advantage (Section 3.4.3) that may attract and retain users. In contrast, violations of privacy and security may repel users and harm a companies’ reputation (Section 3.1.3), thus motivating companies to include it in their strategic planning. To demonstrate such effects, more academic and independent market research needs to be conducted about the economic impact of negative and positive privacy and security reputation. The results need to be disseminated not only in academic outlets but also in mass and social media, business magazines and blogs, and other resources consulted by business executives. Similarly, academic and market research needs to regularly survey user expectations and perceived social norms around privacy, security, and data collection and sharing (Section 3.1.2), and disseminate the results, to raise awareness, dispel potential misconceptions about user beliefs, and engage broader societal groups in discussions regarding privacy and security. Companies’ engagement in user research and direct involvement of users in testing software prototypes could further align the views of software companies’ employees with user beliefs, expectations, and preferences.

Software engineers often believe that privacy and security concerns are not relevant or important to certain products, such as B2B or internal software services (Section 3.4.1). However, practically no software is safe from privacy/security risks. Threat modeling exercises (e.g., using Security Cards²), regular vulnerability discovery activities (e.g., bug bounty, penetration testing, threat analysis), and less formal activities (e.g., hackathons) can help engineers to correctly assess the relevance of privacy/security issues and vulnerability of the systems.

To leverage the personal motivation of software developers, job descriptions need to include the protection of privacy and security as part of the official personal responsibilities of software developers, regardless of whether they are part of the privacy or security team, or not (Section 3.5.1). Direct engagement of developers in code review may also promote their perceived responsibility for privacy and security aspects of the developed system, instead of entirely relying on a security team to do the reviews and making them fully responsible for privacy and security aspects of the system [134]. To leverage instrumental attitudes (Section 3.5.3), companies should emphasize the importance of addressing privacy and security concerns and explain the reasons. In the absence of personal experiences with violations (Section 3.5.5), case studies can be deployed to further raise developers’ empathy and motivation to protect users’ privacy and security. However, they could also try to change the experiential attitudes (Section 3.5.4) by making solving privacy and security issues more engaging, for example, by introducing gamified incentives, organizing competitions and hackathons, and using humor and positive framing in communications about this topic.

Organizational privacy and security culture (Section 3.2.3), including companies’ vision, values, and code of conduct, can emphasize the importance of privacy and security at every stage of software development. Security and privacy champions and advocates act as experts or enthusiasts leading by example [60]. By motivating and encouraging such champions, companies can gradually shift and proliferate positive privacy and security culture to the rest of the organization [17, 117]. (See more strategies for promoting organizational privacy culture in the work of Tahaei et al. [117].) Evidence about the effectiveness of monetary incentives to encourage developers to protect users’ privacy and security is mixed, often suggesting that intrinsic motivation is a stronger predictor than extrinsic rewards [7, 59, 109, 117], thus more research on this topic is encouraged.

The COM-B model defines capability as the physical and psychological capacity to perform the behavior (e.g., engage in the necessary thought processes, like comprehension or reasoning) [87, 88]. To leverage developers’ capability to engage in user privacy and security protection, it is important to ensure an adequate level of privacy expertise and knowledge (Section 3.5.2), for example, through training, peer support, other experts in the company exchanging their knowledge, and other resources (Section 3.2.6). Organizations can encourage and support informal procedures in relation to security and privacy, such as the sharing of empirical problem-solving knowledge among employees and development of personally devised security checklists [7, 132] or validation of security code libraries by peers before implementation [32]. Although peer support, Q&A websites (e.g., Stack Overflow), and other media resources can be more engaging than formal documentation, these sources of information may be less reliable [2].

Requirements engineering tools [136] may enable the identification and prioritization of privacy and security requirements and strategies (Section 3.3.2). Furthermore, better tools for implementing privacy and security best practices would reduce barriers to adoption and improve regulatory compliance. Examples of such tools include privacy-preserving libraries, data mapping tools, databases for implementing differential privacy, or tools for building GDPR-compliant user interfaces for obtaining user consent. It is also important to provide engineers an appropriate level of authority, autonomy, and control (Section 3.5.1) over their decisions about privacy and security features of the systems.

Finally, to support the ability of developers to detect and address privacy and security vulnerabilities, it is important to not only provide appropriate tools and libraries but also make them easy to use (Section 3.3.3). Similarly, internal organizational documentation and procedures (Section 3.3.1) and external privacy and security guidelines and documentation should be readily available to the developers, comprehensive, useful, and easy to understand [79]. It can be achieved by providing security reference guidelines that are adapted to non-experts [70], and by providing reputable interactive third-party security implementations and tools, which could free developers from writing complex security code from scratch [60] and help to reduce programming errors [133].

It is important to create opportunities for implementing privacy and security in software development, for example, by providing management support (Section 3.2.4), including security and privacy in the board’s agenda [12], clearly communicating to employees their support of security advocates [59], and dedicating to privacy and security sufficient financial and human resources (Section 3.2.2), and time (Section 3.3.3), such as by budgeting time for privacy and security requirements and evaluation stages, and set more adequate deadlines and goals. Given that privacy and security are complex issues, companies should improve organizational and team structures (Section 3.2.7) to facilitate communication between teams about privacy and software, increase the diversity of opinions to obtain a variety of perspectives on controversial topics, and integrate privacy and security experts into all software development teams instead of creating a separate siloed privacy/security team.

To create opportunities for evaluation of a system’s privacy and security, it is necessary to incorporate privacy and security reviews, and the principles of privacy-by-design [24], into formal software development practices, provide UI and UX guidelines and templates for obtaining informed consent, and develop metrics for evaluating privacy and security aspects of the systems (Section 3.3.4).