Sunday, 20th September 2020

Privacy + development = securer applications

Privacy and security are essential not only to bring peace of mind to users but also to comply with industry guideline and regulations worldwide. This guide is designed to help developers to apply privacy principles in order to create more secure apps. By Margaret Alston, Consulting Programme Director, TrustArc.

Privacy-by-Design (PbD) is by no means a new concept. It dates back to Canada in 1995 when a report was created by the information and privacy commissioner outlining seven foundation principles on which all information systems should be based. Today, privacy by design has a wider definition and is generally considered as any set of actions which help to ensure privacy is built into systems, applications and even offline processes. It has also played a central role in one particular piece of regulation drawn up in the face of rapidly accelerating technology innovation; Europe’s General Data Protection Regulation, more commonly referred to as GDPR.

The EU GDPR impacted all businesses, from small independent hairdressers to large conglomerates in all 28 European Union member states. It represented the most sweeping effort yet to oversee the way businesses collect and manage consumer data. The law, established to create consistent data standards and protect EU citizens from potential privacy abuses, sent ripples—if not tidal waves—across the world. However, GDPR is still often overlooked in the app developer community.

In this increasingly complex compliance landscape, the GDPR not only demands end-to-end privacy sensitivity but for this to be clearly demonstrated. This requires app developers to anticipate the need for proof of compliance in all systems and processes. PbD tools have never been more relevant to help them consider privacy through their entire development process.

Privacy-by-design standards offer guidelines for product development

PbD can help developers to structure their thoughts when developing GDPR-compliant products, systems and processes. This includes new and faster development cycles that follow launch-and-learn and Agile philosophies. Thinking about Privacy by Design can help developers to consider tactics like pseudonymisation and encryption at every stage, to establish privacy-friendly settings by default, and to ensure that transparent data practices are built into the user interface design. GDPR-compliant development may also require architecture considerations, such as the ability to delete and correct data or to track actions and access, and potentially to provide machine-readable data to a third party as a result of a GDPR request.

In the long-run, organisations should consider the PbD principles throughout the entire engineering process. Those principles include:

·Being proactive and preventative on privacy

·Include end-to-end security for the entire lifecycle of product

·Maintain visibility and transparency for customers

·Respect user privacy by keeping privacy policies user-centric

Check the list to remain compliant

Although the topic of privacy requires a rich conversation across the development team, a PbD checklist is a good place to start on your compliance journey. Leaders can use checklists to demonstrate and document compliance, a requirement of the GDPR, at each stage of the development cycle. The list is where one can tick off actions as they build a system or application with privacy and compliance in mind. These questions can be inserted into requirements, user stories, QA, and user testing.

A GDPR PbD checklist can be divided into two portions, mirroring real life software development teams. These are Front End (User Experience) and Back End (Functionality and Documentation).

Front end (user experience)

  • At each step of the user experience, is it clear to the user what is happening to his or her data and why?
  • Is the data collected and/or used in a way that is necessary for the activities that would be expected by the end user? Is that usage disclosed?
  • If there are any uses for secondary data, are clear explanations provided as to what these are? Can the user easily refuse any of these use cases without impacting the primary service? Does the user have enough context and information to make an informed decision? Is the experience designed so that the user understands the implications of the choices and is not manipulated into making one in particular?
  • If the user is not forced to make a choice, does the default apply the highest privacy setting?
  • If a data use might not be expected in the normal course of the customer/company relationship or might cause customer consternation or concern, is the offered choice an explicit opt-in (rather than an implicit opt-out)?
  • Can the user easily ask privacy and security questions, or make related requests and complaints?

Back end (functionality and documentation)

  • Are data quality assurance measures taken both to prevent bad data coming into the system and to detect inaccuracies in the system?
  • Are there adequate measures to prevent unauthorised access to data?
  • Does the current documentation describe all data fields used/collected, all use(s) for each data field, who is responsible for the system or data, how the data flows through the organisation, what third parties are involved in the system, and the data retention period that applies?
  • Is it possible to identify for a requesting user what data the organisation has about them? Can the user delete data, correct data, and stop or limit data from being processed further?
  • Is there documentation that describes the process of how privacy has been considered at each step in the development process?
  • Have involved third parties been adequately evaluated?

Mitigating privacy mistakes requires thought

It’s 2019 and the global privacy landscape has never been more complex. Over 50 laws have been adopted in the last 12 months across the world, countries including the US, India, Nigeria and all member states of European Union. Here in the UK, it is imperative that organisations consider privacy standards throughout the entire lifecycle of their products if they want to avoid the threat of crippling fines from the ICO (Information Commissioner’s Office). This process begins with app development, so our checklist of PbD principles is a good place to start.

How IT managers protect corporate networks from targeted attacks By Chris Connell, Deputy Vice Pre...
Why business decision makers should expand their network security strategy, By Chris Connell, Deput...
By Miles Tappin, Vice President, EMEA at ThreatConnect.
By Mikkel Stegmann, Principal Scientist at Fingerprints.
Digital transformation needs security at heart, says Jonathan Whiteside, Principal Technical Consult...
One dataset to rule them all, one team to find them. One tool to bring them all and the database bin...
The rise of the Chief Data Officer (CDO) has been meteoric in recent years. Despite being one of the...