Privacy by design for developers improving data protection practices

Twenty years ago, I was that software developer who thought privacy was a blocker. I was upset  that I didn’t get access to personal data easily. As a web developer at a university, I thought jumping through hoops to access basic tables of student information was exaggerated. (I don’t think that now.) I took it personally and was pretty upset with the database manager who was protecting the data. I owe them a huge “mea culpa!”   

These days, I’m the privacy engineer who is trying to protect data. I have worked with hundreds of software engineers to tell them to fix their code or change features because privacy is important.  If engineers think I’m blocking their work, they aren’t wrong.  But since I’ve been on both sides of this discussion, I approach the conversation with understanding and empathy.  I look for ways to change the system so that “Privacy by Design” can accommodate software engineers, instead of creating frustrating feelings.  

Additionally, I’ve interviewed developers about their pain points when implementing different privacy-enhancing technologies.  I’ve done this internally for tech companies to improve their privacy processes, and I’ve also published research to help the academic privacy community better understand and quantify the problem.  

Almost all software engineers and data scientists I talk to want to do the right thing, but systems and processes can get in the way. It’s important to get the processes right. If your company has personal data,  you are relying on your software engineers and data scientists to handle that data with care and implement features in a privacy-protective way.  I’m here to give a few actionable tips to make the process more smooth. 

Since it’s important to enable developers to integrate data protection and privacy into their work, let’s discuss a few hurdles and how to overcome them. If you can anticipate them, you can prevent them.  

1. It’s hard to define privacy, much less translate it into code. Privacy is contestable and does not lend itself to clear definitions, which can be frustrating. A software engineer’s job is to translate ideas into machine-readable definitions. Now we present them with privacy - an idea that can barely be defined. As some researchers found when trying to get programmers to implement privacy, “Because of the difficulty to relate privacy requirements into techniques they could implement, participants also claimed that application of privacy into a design was complex.” This was also my frustration when I first read about “Privacy by Design.” I loved the idea but didn’t know how to operationalize it as a coder. (Since then, more work has been done to make it practical: see https://www.privado.ai/post/operationalizing-privacy-by-design )

2. Privacy is a non-functional requirement and therefore de-prioritized. In practice, functionality and specifications may not include concrete privacy requirements.  Unless privacy is called out explicitly, developers are not incentivized to work on it. There is too much work already, and the timeline is too tight. In my study on app developers, I found that developers consistently discussed the constraints such as time, effort, and money it would take to implement best privacy and security practices.  Other research found that since software engineers “identified [privacy] to be non-functional they considered system requirements should be given priority over privacy requirements.”

3. Developers have to leave their workflow to deal with privacy. When I’m coding, I want to stay in my environment as much as possible, which means I don’t want to leave my bug tracker, my developer environment, and a browser to read documentation.  Some privacy processes require developers to talk to someone or fill out a survey. It feels hugely interruptive. I’m not the only developer who feels this way. I worked with a company with support for privacy-enhancing technologies, but developers said they would do almost anything rather than have to reach out for in-person guidance on implementing them.  

If you are leading privacy efforts in your organization, what can you do to address these issues?  First, acknowledge that privacy and security can be challenging. This is what helped me move into the field of privacy engineering; I liked the intellectual challenge of an interesting problem. Your engineering team might find this compelling as well. Even if you don’t expect your engineers to be privacy experts, incorporating non-functional requirements into their program or code can be hard.  Acknowledge that developing privacy can take time and effort, and at the same time, take these steps to improve the processes around privacy.  

Incentivize privacy personally: Specifically, call out privacy and security in the job description and engineer promotion requirements. The goal here reward engineers for working on a hard problem. Create a culture where engineers don’t have to be experts to contribute to the privacy conversation, but they do need to contribute.  

Make privacy a clear requirement. Call for privacy explicitly in feature requirements.   Include privacy in KPIs or OKRs, specifications, and documentation. You might work with product managers and program managers or the engineering director to make this happen. 

 Go with the engineering flow:Where possible, include privacy in the existing development tools and workflow.  Bugs, tickets, and as much documentation as possible should be in the formats and places your engineers look.  When you cannot include privacy in the regular workflow, acknowledge that it is interrupting their flow and give them time and space to switch contexts.  If meetings are needed, try to schedule them around other breaks in the programming flow (e.g. lunch or other meetings) to minimize task switching. If possible, when choosing privacy management tools for your organization, make them accessible to engineering teams, so they can work with and give feedback directly. (Learn how Privado does that here: https://www.privado.ai/post/privacy-code-scanning) 

For privacy professionals looking to persuade and influence software engineers, I hope these tips help you work with your software engineers. Making privacy part of the organizational culture will help remove roadblocks. Acknowledge that privacy is hard, but then make the processes as easy as possible. You now have specific ways to improve Privacy by Design for your development team.