Integrating Privacy by design
We have all heard of Privacy by Design, it is widely spoken about. Privacy experts consider privacy by design to be the solution that overcomes compliance gaps and builds sustainable privacy programs. We have heard that a compliance centric approach is no longer recommended, and that privacy will have to be made the default setting. This is all true, but what does it mean to implement privacy by design? How can we make privacy the default setting within our companies?
In the past years, within the U.S, we have seen companies build privacy solutions around specific state privacy laws applicable to them. However, this may not be a sustainable solution as the privacy regulation landscape in the U.S is continuing to evolve. States like Texas and Florida have their privacy laws going into effect in 2024, while some states like Ohio and Maine have active privacy bills as of 2023-year end. Moreover, even if the requirement is to comply with just one state law, it is not possible to fulfil the compliance requirements without implementing privacy by design.
With 2024 around the corner, which will see the implementation of new privacy regulations as well as the introduction of many privacy bills and proposals, let us look at some actionable steps and strategies to seamlessly integrate Privacy by Design into everyday operations.
Privacy by Design is a concept that focuses on designing technology and building business processes while keeping the privacy of individuals and regulatory requirements in mind. This concept makes privacy the default setting, rather than opting for a compliance centric approach. While many consider this approach cumbersome, it actually is efficient and saves time. When we have a proper understanding of the data; how it is going to be used, whether we have obtained consent for it, who has access to it etc., then it will be easier to understand how and when it should be destroyed and put processes in place accordingly.
Privacy by design focuses on 7 primary principles:
Proactive not Reactive; Preventative not Remedial
Privacy as the Default setting
Privacy embedded into design
Positive-sum not zero-sum
End-to-end security
Visibility and Transparency
Respect for user privacy
Practically implementing these principles is often not as straightforward as we might think, here are some of our strategies that we can implement in the new year to introduce this approach:
When looking at implementing any change within our company, we first need to organise this change by looking at the ‘Why’ and the ‘How’. Once we have solid answers to these two questions, it becomes easy to introduce any change at all levels in the company. The answers to these two questions aid the communication with various teams and personnel within the company.
Communicating the ‘Why’ and ‘How’ with engineering teams is one of the most important steps while implementing privacy by design. This coordination and communication with engineering teams is crucial as they are the ones developing products and services and making changes to existing ones. For example, integrating SDKs that are privacy compliant, integrating with third parties for cookie compliance, setting up the IAB Global Privacy Platform (GPP) are some of the many strategies that support privacy by design. However, these strategies cannot be implemented without proper communication and coordination with the engineering teams. When user stories and epics are written, they need to be done keeping the privacy requirements in mind, which again cannot happen if they don’t understand the ‘Why’ and ‘How’
The ‘Why’ has already been established. Privacy is the way forward today and privacy by design is required to comply with regulatory requirements. Let’s also look at the ‘How’ below.
When considering the seven principles of privacy by design, it is important to identify key focus areas or processes that could help achieve the privacy by design principles. For example, we can look at the second principle, privacy as the default setting. This means that users are already subject to the highest data privacy settings without them having to choose those settings themselves. This can include data minimization, appropriate data destruction, etc. Which can further be broken down into - collecting only the amount of data that is legally allowed, collecting data only to the extent required for the purposes for which they are collected, applying data deletion schedules on data depending on their purpose, etc. This becomes easier when we understand the purpose of data collection. Having a clear understanding of the data that we actually require for the business’s needs, be it enhancing user experience, marketing, analytics, etc will enable us to collect only to that extent, obtain consent for exactly that and set retention processes in place accordingly. This may require different teams like marketing and product management to come together to outline their needs for data to get a clear understanding of what data they require for their processes.
We can look at the third PBD principle as another example - Privacy embedded into design. In this case, the engineering teams will have to consider privacy while developing new products and services. For example, when building mobile applications and smart devices, privacy should be built into the Software Development Lifecycle. Meaning that privacy should be incorporated during the scoping and planning stages, it needs to be a part of the software architecture, data sinks should be monitored, versions and modifications should be closely examined, etc. An in depth resource on implementing privacy into software design can be found here. Again looking at mobile applications and smart devices as an example, privacy forward SDK providers will have to be chosen like those which allow the preference of users to be collected and sent back to the provider or those that allow users to stop the tracking of their data. Here, the engineering teams should choose privacy compliant SDK providers and carefully study the documentation given by them.
In certain cases, it can be easier to introduce changes into some existing processes. PIA’s can be conducted on user stories and epics to ensure that any new upcoming changes are written and created in a way that is compliant with privacy regulations.
Next, we want to be able to measure the success of the processes or key focus areas as this will in turn measure the success of the PBD principles. Key Performance Indicators (KPIs) can be used to understand how the principles have been implemented, their effectiveness, the quality of the design, etc. Software products like Jira can be utilised to help development teams track and understand tickets, bugs, and other issues. User stories and epics can be pulled and reviewed to understand the extent to which they have considered privacy. Integrating PIAs with user stories and epics is great way to measure the success of your privacy requirements on new changes and features.
The privacy by design approach may seem like a time-consuming endeavour to take up, however, once it is put in place, it is sustainable and ensures compliance with existing as well as possible upcoming regulations. It builds trust with users and has a positive impact on other business processes. In our next articles we will be looking at PIAs; how they play a role in this approach, technologies that enable this approach as well as hurdles that we face with its implementation in today’s regulatory landscape.
