Image credit: Martin Newhall, Unsplash

Above: Photo by Ian Keefe on Unsplash

With the General Data Protection Regulation (GDPR) looming, the challenge for design and management is to understand how to integrate privacy and security by design into a product, or platform, effectively. Product managers, or product owners, are expected to know their product inside out. But how much do you know about your product when it comes to privacy and security? How are you integrating it into your product team’s workflow? For most of us, this is a learning curve.

If, when developing a new product or platform, privacy and security is embedded throughout the system design process, privacy will be smoothly integrated into your product ,  allowing it to be secure from the start.

Implementing privacy and security by design into an existing product is more difficult. You need to deconstruct and analyse the existing system, which means carrying out a privacy and security audit on your product, from start to end. You need to consider how privacy has been embedded, find any risk areas, and add new user-friendly solutions into your product roadmap to ensure improvements with each iteration.

When auditing your product consider the following

  • How is privacy and security by design embedded into the architecture?
  • How is privacy and security by design embedded into product development in general?
  • Is end-to-end encryption, including data at rest, done by default?
  • Does the product protect the privacy of the user by default in every process where personal data is being handled?
  • How do third parties handle security and privacy of personal data, in relation to where your product is run and personal data is stored or processed?
  • Does the UI include privacy controls for the user?
  • Are we really only collecting what is necessary?
  • Do we know what metadata, logs and debugging logs contain personal data?
  • Does the product live up to the obligations outlined in the Privacy Policy?

In her guide to implementing strong privacy practices, Ann Cavoukian of Global Privacy and Security by Design lays out a few key principles to consider when embedding the privacy by design framework. These can be assigned to any business practice or IT system, but in this post I have summarised them with regards to product management.

Principle 1: Proactive not reactive (Preventative not remedial)

Anticipate and prevent breaches from occurring.

Recognise the value and benefits of proactively adopting strong and consistent privacy and security practices for your product. Ask yourself whether your product could withstand the risks that privacy by chance or privacy by disaster would bring.

Further reading illustrating proactive rather than reactive product management:

Principle 2: Privacy as the default setting

The product should provide privacy assurance, giving the user the maximum privacy by default. A user should not have to take actions to protect their privacy within your product.

Default product settings should be privacy preserving. Encourage the product team to think beyond the default settings or preferences that users control to the overall system defaults.

When designing a new product, or feature, it should always maximise privacy, beginning with no personal data collection, unless and until a specified purpose is defined.

Data minimisation is the first line of defence. The collection, use or disclosure of aggregated, de-identified personal data also raises privacy issues. We often apply paper world requirements to a digital world. Online systems actually require less data because of their computational capabilities.

Personal data that is not collected, retained or disclosed needs no securing.

Further reading illustrating privacy as the default setting:

Principle 3: Privacy embedded in design

Privacy and security should not be an add-on, after thought or after-breach consideration. When it comes to product design and development, it should be rolled into the core functionality.

Poster: 7 Laws of Identity by Kim Cameron

Development and design should be approached in a holistic, integrative and creative way, moving away from a reactive model to a proactive one.

It is essential that all interests and objectives, including privacy, are documented, and that desired functions are articulated and metrics agreed upon and applied. Reject trade-offs in favour of finding a solution that enables multi-functionality.

Privacy expertise must be available and engaged throughout all phases of the workflow, not purely at development or design stage, bringing an appreciation of client expectations.

As a product manager, consider the following.

During design and development, could we:

  • Design reporting features that allow users to be notified of how personal data is being collected by our application, and whether any exceptions to their privacy preferences have occurred;
  • Provide simple, easy to understand user interfaces for privacy controls;
  • Use privacy-protective default settings;
  • Ensure end-to-end protection of personal data;
  • Not require social media registration to access the app;
  • Not enable sharing by default;
  • Include an option to show users their personal data;
  • Unbundle or separate consent;
  • Include better user-management features:
  • Minimise your application’s access to device data; and
  • Integrate privacy by design into the development cycle.

As a product team, could we:

  • Find ways to educate users about the risks associated with personal data;
  • Conduct annual assessments of privacy and security by design in our product.
  • Conduct annual reviews of the privacy policy for the product.
  • Revisit contact forms, sign-up pages and customer-service entry points.
  • Enable the regular deletion of data created through these processes.

At the end of engagement and mothballing, could we:

  • Remind users to review and refresh their privacy settings;
  • Ensure the contracted retention details are adhered to;
  • Allow users to download and delete old data;
  • Delete the data of users who have closed their accounts; and
  • Delete all user data when the app’s life comes to an end.

 

Further reading illustrating privacy embedded in design:

 

Principle 4: Full functionality (Positive-sum, not zero-sum)

Ensure that legitimate interests and objectives are accommodated in a positive-sum, ‘win-win’ way. Do not resort to zero-sum where unnecessary trade-offs to privacy are made in the product.

In a zero-sum view, in order to enjoy privacy, we must give up other functionalities that we value, such as security, safety, system efficiency, flow of information, or business interests. This is an outdated, yet mainstream, way of thinking.

Respecting people’s privacy should never present a barrier to delivering a service. Products should be built with privacy in mind, providing a double-enabling outcome (positive-sum).

Principle 5: End-to-end security (Full lifecycle protection)

Security is key to privacy. There should be full lifecycle management of information so that personal data is properly secured and not retained for longer than necessary. We are responsible for the security of personal data stored by our product throughout the data’s entire lifecycle (at rest, in transit, and while in use).

Security, of course, is not just about encryption or destruction of data but covers a wide area, outside of product management and development. Product managers should be aware of which providers are being used for their products and how they stack up security and privacy wise.

DevOps should assess third party cloud providers on:

  • How proven their security stack is. Are they running different patch levels on different hardware?
  • How large they are. How resilient or redundant are they? What is their recovery time objective?
  • The speed and agility at which they work. How quickly do they adapt to security issues today? Which peer groups do they work with for security information gathering?

For developers and designers, security should be a core principle when designing the product or feature. Before any code is written, the design should get a security review. Code written by the product developers should be peer reviewed for security and least privilege (ie. minimising access)

When relying on third party code, such as open source components, make use of an inventory and vulnerability checking tool such as OWASP Dependency Check.

Static code analysis (SCA) is a quick and automatic check, without having to execute the code. It works to discover issues that are hard to discover manually.

Secure destruction of personal data, is also part of secure data handling. We need to follow responsible, secure procedures for destruction of personal data once a decision is made not to retain the data.

 

Further reading illustrating embedding of end-to-end security:

 

Principle 6: Visibility and transparency (keep it open)

Stakeholders must be assured that the privacy and security promises and objectives for the product are transparent and independently verifiable.

Visibility and transparency are essential to establishing accountability - not only for individuals but also for business partners and other stakeholders. It is increasingly in the interests of everyone, from developers and system architects to organisational leadership, to be transparent and accountable when it comes to privacy.

The implementation of privacy by design opens up a stream of dialogue between organisations and the end-users they serve. Effective communication with users is the essential link between implementing strong privacy practices and fostering the consumer confidence and trust that leads to sustainable competitive advantage.

Users need to be advised in a timely, actionable, simple manner of any important system privacy attributes, including which privacy policies apply and who is responsible for them.

Principle 7: Respect for user privacy (keep it user-centric)

The product should keep the interests of the individual uppermost by offering strong privacy defaults, appropriate notice and user-friendly options.

Respecting the user means that when designing or deploying a platform or product, an individual’s privacy and user interests are accommodated.  The product needs to anticipate the user’s privacy perceptions, needs, requirements and default settings.

On the operational side, the product needs to assure transparency, attain informed user consent, and provide rights of access and correction. Users expect privacy preferences and settings to be clear, to function across the platform and to persist over time. These should cascade to third parties utilised (ie. cloud providers, etc).

Empowering users to play active roles in the management of their personal data may be the single most effective check against misuse and abuse of personal data. As such, this principle has important links to the field of user interface design. The user interface should allow maximum user control over personal data and its processing by others.

 

Further reading on user-centric approach to privacy:

 

 

Conclusion

In conclusion, regardless of the size and structure, any organisation that encounters personal data must effectively manage and protect it.

Products are increasingly being judged based on the privacy and security they provide, while organisations are judged on the knowledge they share and the commitment they have to ensuring personal data is protected. This presents immense opportunities in the market for organisations or products ahead of the game.

Every team or organisation will integrate privacy and security by design into their products in their own way. All will face different challenges and accrue lessons learned, which will grow best practices for the benefit of all.

At Akvo, we are committed to improving our products by incorporating the privacy and security by design framework into our processes. Our partners entrust the personal data they capture to us, and we have an obligation to protect it as best we can.

 

Lynn Greenwood is GDPR-lead and product manager at Akvo. You can follow her on Twitter @lynngre.