Why You Should Not Rely on Your Developers as Privacy Experts

Today’s developers have a lot of responsibilities. Not only do developers have to create robust functionality that is helpful to their users, but they are also releasing this functionality into production quicker than ever before due to a Continual-Integration/Continual-Delivery culture.

Functionality must be created to secure the application’s sensitive data, protect the users of the application, and defend the production environment from malicious attackers. Adding even more responsibility, recent data privacy legislation also places demands on how development teams store, share, and process their users’ data.

Thankfully, there are data privacy policies and processes that development teams can implement that will help them mitigate the risk of non-compliance with data privacy legislation. A few of the most useful policies and processes include:

1. Create a data classification policy and enforce it.
    The software development team should not be responsible for understanding what data is sensitive and protected by legislation and which data is not.
   Software developers are often not subject matter experts when it comes to understanding the data their applications are processing. The creation of a data classification policy by actual subject matter experts will mitigate the risk of a developer making an incorrect assumption about the data that could lead to a privacy violation.
   
2. Create an incident response plan for when data privacy violations are reported to the organization.
   In the past, many data privacy incidents have been mishandled or ignored by organizations.
   This lack of an incident response plan has led to these organizations being embarrassed when the privacy violations are publicized and has sometimes resulted in the organization being fined for these errors. Assuming a data privacy violation event will occur in the future and planning a response helps to mitigate the risk of making a bad situation even worse.
   
3. Create a data archival, retention, and deletion policy.
   By defining the development team how user/customer data will be handled, sloppy data handling practices can be avoided.
   For example, it is common for developers to want to use actual production data to test applications in development. However, there are often laws that protect this data from exposure, so having a data retention policy that describes how the data must be masked or anonymized before it is used for any reason outside of its initial purpose, is suggested.
   

While these three data privacy best practices are an incomplete list of policies and processes that can be used to mitigate the risk of a privacy violation occurring, often these policies and processes can be defined by subject matter experts outside of the development team. While the development team is still responsible for following the data privacy best practices, they should not be responsible for their creation.

By placing this responsibility into the hands of subject matter experts, organizations can reduce the risk of software engineers making incorrect assumptions about how data privacy legislation regulates how certain data must be handled.