Privacy by design necessitates addressing privacy problems throughout the system development life cycle. Privacy protection, under this paradigm, is a system requirement, just like any other functional requirement, that must be addressed from the start and defines the system’s ultimate design and execution. We need guiding principles to resolve privacy requirements across the system development life cycle, particularly throughout the idea development, analysis, design, and implementation phases, to promote privacy by design. To that aim, this blog post outlines the eight basic privacy design strategies.
Strategy #1: Minimise
The amount of personal data processed should be kept to a bare minimum.
The potential privacy impact of a system is limited by ensuring that no, or no unneeded, data is gathered. Data minimization can take two forms: either a yes/no decision to collect any information about individuals (as a result, no information will be gathered at all for certain persons), or limiting the amount of information collected about each person to a limited range of attributes. Select before collecting, anonymization, and the use of pseudonyms are all prevalent design patterns.
Strategy #2: HIDE
Any personal information that is processed should be hidden from plain view.
Any personal data, as well as their interrelationships, should be shielded from plain view, according to HIDE. The idea behind this method is that personal data cannot be easily abused if it is hidden from clear view. The strategy does not specify who the data should be kept hidden from. This, of course, is dependent on the circumstances in which the approach is employed. When a strategy is employed to hide information that spontaneously emerges through the use of a system (for example, communication patterns), the goal is to keep the information hidden from everyone. In other circumstances, where information is properly gathered, held, or processed by one party, the goal is to keep it hidden from others. The usage of encryption (locally or over the network via SSL), onion routing to disguise traffic patterns, and anonymous credentials are all common design patterns.
Strategy #3: SEPARATE
Personal data should be processed in a distributed fashion, in separate compartments whenever possible.
Complete profiles of one person cannot be created by separating the processing or storage of different sources of personal data that pertain to the same person. Separation is also an useful way to achieve purpose limitation. Separation technique necessitates dispersed processing rather than centralised solutions. Separate databases should be used to store data from different sources, and these databases should not be linked. When possible, data should be processed locally and kept locally if at all possible. When possible, database tables should be separated. These tables’ rows should be difficult to link to one another, for example, by deleting identifiers or utilising table-specific pseudonyms.
With the emphasis on centralised web-based services these days, this method is frequently used.
Strategy #4: AGGREGATE
Personal data should be processed at the highest level of aggregation and with the least possible detail in which it is (still) useful.
Personal information becomes less sensitive when the amount of detail is limited or when it is considered at the group level rather than individually for each person. Little information can be ascribed to a single person when the information is coarsely grained and the size of the group over which it is aggregated is large enough, ensuring their anonymity.
Aggregation over time (for example, utilised to provide some level of privacy protection in smart metering and smart grid systems), and dynamic location granularity are common design concepts (used in location based services where the accuracy of the reported location of a user is adapted dynamically to ensure that a reasonable number of other users are at the same location).
Strategy #5: INFORM
When personal data is processed, data subjects should be appropriately informed.
When data subjects utilise a system, they should be informed about what information is collected, why it is collected, and how it is collected. This involves providing information on how information is safeguarded and being open about the system’s security. It’s also a good idea to make clear design documents available. Third parties with whom information is shared should also be disclosed to data subjects. Furthermore, data subjects should be made aware of their data access rights and how to exercise them.
Transparency, the (now largely defunct) Platform for Privacy Preferences (P3P), and data breach notifications are all possible design patterns in this area.
Strategy #6: CONTROL
Data subjects should have control over how their personal data is processed.
In reality, the CONTROL approach is a critical complement to the INFORM strategy. There is little point in alerting a data subject about the collection of personal data if there are no reasonable means of controlling how that data is used. Of course, the contrary is also true: asking for consent is pointless without adequate information. The data subject frequently has the right to see, amend, and even request the erasure of personal data acquired about her under data protection legislation. This strategy emphasises this point, and the design patterns in this class provide users with the tools they need to exercise their data privacy rights.
Control, on the other hand, extends beyond the rigid application of data protection laws. It also affects how consumers decide whether or not to utilise a certain technology, as well as how they control what information is processed about them. The simplicity with which a user can adjust his privacy settings via the user interface, for example, defines the level of control to a considerable extent in the context of social networks. As a result, user interaction design is also vital.
Control is supported by user-centric identity management and end-to-end encryption.
Strategy #7: ENFORCE
There should be a privacy policy in place that complies with legal standards, and it should be followed.
This is a crucial step in ensuring that a system’s operation respects privacy. Obviously, the actual level of privacy protection is determined by the policy. It should, at the absolute least, comply with legal standards. As a result, this technique also covers purpose limitation. But, more significantly, the policy should be followed. At the absolute least, this indicates that sufficient technical safeguards are in place to avoid violations of the privacy policy. In addition, proper governance structures for enforcing the policy must be put in place.
Certain types of access control and systems that handle privacy rights management could be design patterns that apply this method (a form of digital rights management involving licences to personal data, but then applied to privacy).
Strategy #8: DEMONSTRATE
A data controller must be able to verify that the privacy policy and all other legal obligations have been followed.
This technique takes the enforce strategy a step further by requiring the data controller to demonstrate that it has control. This necessitates the data controller’s ability to demonstrate how the privacy policy is successfully implemented within the IT system. In the event of a complaint or an issue, he should be able to quickly establish the scope of any potential privacy breaches.
Privacy management systems, as well as the usage of logging and auditing, are examples of design patterns that apply this strategy.
How Can ITM Help You?
IT Minister covers all aspects of Cyber Security including but not limited to Home cyber security managed solutions to automated manage Threat Intelligence, Forensic Investigations, Mobile Device Management, Cloud security best practice & Network & Security Architecture and cyber security training. Our objective is to support organisations and consumers at every step of their cyber maturity journey. Contact Us for more information.