More stringent privacy regulations have forced organisations to take a serious look at how they implement and manage privacy. For organisations that have already put in place well-defined privacy objectivesand the policy and compliance instruments to monitorthose objectives,the next challenge is toimplementprivacyacross all of their products and services. The challenge is especially profound for organisations that are customer facing, where products and services make increasing use of personal data, open source code, 3rd party APIs and extensive data sharing between ecosystem partners.
Use of open source and APIs can lower costs by reducing time to market but it requires engineers to trust that the source code and services they are using can, and do, protect personal data to the degree that their organisation requires. Some of this trust can be verified by scanning code and APIs for vulnerabilities but the tools available do not validate that privacy by design principles have been applied. This creates gaps in the privacy chain which generates the need for additional risk management.
Tracking the movement of personal data as it flows from the point of collection, or creation,through multiple applications or services that together make up a productoffering is challenging, and in some circumstances impossible,yet that is now a requirement of mostprivacy laws. Thischallenge falls to the product or service designers and engineers but the first, and perhaps most difficult step, is to translate privacy objectivesderived from a combination of what an organisation would like to achieve, applicable laws and regulations into technical and operational privacyrequirements.
From Legal Documents To Privacy Requirements
To complete the first part of the process, product owners identify all of the personal data that a system is likely to use. Working with legal and domain experts they canthen apply applicable privacy lawand industry regulations to the data.Ultimately, all of the applicable privacy standards, guidelines and laws must be traceable to known requirements that can eventually be tested. The ability to complete this translation will determine the quality of the product when measured in terms of its ability to meet high standards of privacy. There are no standard methods to determine how accurately this process has been completed but the level of completeness will improve over several iterations. In any case, an iterative approach is necessary since legal teams and engineers will need to establish close working relationships in order to ensure that as changes to privacy laws occur the impact can be quickly assessed and necessary adjustments made to the requirements.
During the next phase privacy engineersensurethat controls required to secure personal data are considered at every stage of the product development lifecycle. The features that support privacy are therefore embedded in the product not only at the time that it is launched but also during the product support and maintenance lifecycle. Here, the process needs to focus on the life cycle of eachdata item in the context of the systems within which they are being used. From creating adata element, through usage, storage, sharing and finally deletion, engineers need to understand the considerations that need to be attached to each. Design decisions such as: how and when data is created, the encryption methods that are used, when and how data must be deleted are generated.
It will not always be possible to design technical controls that support privacy requirements so engineers will also need to work their legal teams and product managers to define appropriate risk management strategies. Naturally, these should be aligned with product or service launches.
Increasingly, ethical considerations are being given to the use of personal data. Depending on the underlying technologies that are used, privacy engineers may need to translatethe outcome of any ethical discussionsregarding the intended use of data into additional requirements. With many emerging technologies legal consideration may not yet have been given to the potential impact on personal data. Existing laws may be insufficiently clear leading to misinterpretation or deliberate misapplication. Where no precedent has been set products can be released into a regulatory vacuum in which case ethics provides the only guidance as to what is acceptable.
All of thesechallenges are more intensewhen operating across jurisdictions or where applications are used across different domains. The finance and healthcare sectors, for example, are subject to domain specific regulations that must be considered alongside general data privacy provisions. Working in these scenarios generates requirements that are contradictory, misaligned or that cannot be easily combined. Engineers are forced to create generic products that attempt to provide a common level of privacy or multiple product variants. Both options create additional risks.
Process and Tooling
Privacy engineeringis relatively new. Whilst there are many frameworks that provide guidance regarding its application there few options for tools that can be integrated into the analysis, development and test cycle. This will change over time but in the meantime engineers would benefit from tools to enable a consistency and completeness in their deliberations.
The LINDDUN model is an example of a privacy threat modelling framework that can be useful in improvingprivacy requirements once the types of personal data that will be created or used in a system havebeen identified. It adds a threat modelling process to traditional data flow diagramming techniques so that engineerscan consider and address requirements for, and potential threats to,each data item at every stage in its lifecycle. Once these have been identified designers can determine the most appropriate controls. This modelcould also be used to address concerns regarding what happens to data as it passes across system boundaries into systems that have been developed or that are managed by 3rdparties. In this scenario organisations can work collaboratively with their partners to apply the model across systems.