Kick-off

Plan ongoing collaboration

You should involve other stakeholders in privacy discussions as soon as you can:

• You should identify your colleagues in data protection or legal teams if you have them. Introduce yourself and the project early. It’s easier to discuss and resolve privacy questions as you go than at the end, when you may need to change key design decisions.
• Your organisation must have a lawful reason for processing personal information, and may need to complete a data protection impact assessment (DPIA) for your project. Discuss with your legal or data protection colleagues whether you could help with this work. A product or service might use different lawful reasons for particular features.
• You should also consult with other senior stakeholders, as required. For example, you may need sign-off from product leaders or technology teams. Plan milestones or activities to raise privacy issues with these stakeholders: don’t just wait until final approval.
• You could record discussions and actions in a central location, such as an intranet or wiki. This will help teams who work on the product in future to see your working, and help you demonstrate compliance.

Map what personal information the product needs

Every product is different, and within a product different features often have quite different purposes:

• You must consider what personal information your product might use across its entire range of features. The definition of personal information is wider than many people realise, so check carefully.
• To keep track of the personal information you handle, you could create a visual map showing how you will collect and process information through your product. Keep this updated as the feature or product evolves.
• If any of the personal information you are processing is classed as special category data, your organisation must meet additional conditions to process it. This covers particularly sensitive personal information types such as religion, race, and sexual orientation, amongst others.
• If children are likely to access your service, even if they are not your target audience or user, you must consider the Children’s code.
• You should consider how people will interact with your product. Is your interface graphical, textual (eg a chatbot), audio (eg a smart speaker), or something else? Every mode of interaction can raise different privacy concerns.

Identify changes and risks

Based on the data sources and flows you’ve identified, look for potential privacy risks that might arise:

• Your organisation should review whether new uses of personal information introduce new risks to people’s rights and freedoms. In addition to information that people provide directly, your organisation should consider personal information you obtained by observing user activities, or that you infer or derive another way.

• You should examine the relationship between your organisation and your user. If you hold a lot of information about people, or have significant power over them, privacy risks might be higher. People may feel unwilling to exercise their rights or to give consent freely if they think it could disadvantage them.
• You should check whether your new product or feature could create knock-on privacy problems for existing features. For example, allowing people to edit private messages after they have been sent could allow hostile users to cover their tracks after leaking data.
• You should think about how bad actors or attackers could use new sources of data maliciously.

Agree responsibilities

Add time in your roadmap for privacy reviews and potential changes, and for validating your approaches through testing:

• You should agree with your stakeholders who is responsible for taking privacy decisions. If you have one, a data protection officer may have final accountability, but you should also consult senior stakeholders. Also, you should discuss who you need to keep informed about key decisions.
• You should talk with your engineers or developers about setting up appropriate logs or alerts. You could, for example, build systems that alert teammates to privacy-threatening bugs, or to capture audit trails of what happens with personal information and who accesses it in the system.

Weave privacy into your business case

Early in a project’s life you will have to explain the value of the work. This is a perfect opportunity to discuss the advantages privacy offers and how you might measure them. For example, you could do the following:

• Communicate the value of privacy in your business case. This could include reducing the risk of damaging mistakes, or lowering likely support costs by allowing people to exercise their individual rights directly.
• Embed privacy into your success metrics, so you meet desired outcomes while still keeping people’s personal information safe. Privacy-specific KPIs or OKRs (objectives and key results) can also help you monitor privacy issues and provide early warning of problems.
• Discuss how privacy-enhancing methods lend you an advantage over competitors. If people feel safe on your platform, this may lead to more loyal use and a trustworthy reputation that can differentiate your sales and marketing.
• Write a pre-mortem – an imaginary article looking back from the future on your feature’s perfect launch or failure – to help you focus on the privacy aspects that will ensure success.