This document discusses data privacy in cloud-native applications. It defines key concepts like data privacy, data security, and privacy engineering. It outlines the 7 principles of GDPR including lawfulness, fairness, transparency, and others. It notes that data privacy laws are expanding globally and becoming crucial for business as more developers build features using microservices and third parties. Engineering teams are increasingly complex and privacy teams cannot keep up with mapping data flows, documenting privacy controls, and identifying risks. The document introduces Bearer, a tool that can catalog engineering components, map personal data flows, and automatically trigger risk assessments to help privacy engineers monitor privacy risks continuously without code changes.

1. Data privacy in the age
of cloud-native
applications
Guillaume Montard
Co-founder & CEO at Bearer.com

2. ➔ Data privacy
◆ The right of an individual to have control over their personal data and the technical
procedures to ensure these rights.
➔ Data security
◆ Protecting data from any unauthorized access or malicious attacks.
➔ Privacy engineering
◆ Methodologies, tools, and techniques used by engineers to integrate privacy
principles into product building processes.
Key concepts

3. 1. Lawfulness, fairness, and transparency
2. Purpose limitation
3. Data minimization
4. Accuracy
5. Storage limitation
6. Integrity and confidentiality (security)
7. Accountability
The 7 principles of GDPR

4. ● Privacy laws are everywhere, for e.g.:
○ GDPR in 󰎾
○ CCPA in 󰑔
○ LGPD in 󰎙
○ PIPL in 󰎩
● By 2023, 65% of the world’s population will have its personal data covered under modern
privacy regulations (Gartner).
● Data privacy is simply becoming crucial for business.
Data privacy is paramount today!

5. ● More developers than ever committing features every day.
● Evolution of architecture around microservices.
● Increasing usage of third-party services.
Engineering organizations are increasingly complex

6. Privacy teams can’t keep up
1. Map personal data flows.
2. Document privacy
and security information.
3. Identify privacy risks.

7. The (Bearer) way 🐻

8. Why?
● To keep visibility over the software architecture.
How?
● Build a catalog of your engineering components: repositories, databases, 3rd-party APIs…
1. Identify your engineering assets

9. Why?
● To understand how your product processes personal data.
How?
● Enrich inventory with personal data processed by the engineering components.
2. Map personal data flows

10. Why?
● To identify privacy risks.
How?
● Enrich inventory with privacy and security information:
○ E.g: data subject, lawful basis, data retention, security measures, DPA, etc.
● Identify gaps against data policies
3. Audit privacy and security controls

11. Why?
● Detect privacy risks proactively.
How?
● Automate the previous tasks with dedicated tools.
4. Monitor continuously

12. Empowering Privacy
Engineers

13. What?
● We help security teams at tech companies identify data security and privacy risks.
How?
● Scanning the codebase to catalog engineering components, map personal data flows and
automatically trigger risk assessment workflows.
Why this way?
● No code changes require, no connection to your databases or access to any data.
Bearer in a nutshell
Curious? 👉 Drop me an email at guillaume@bearer.com

14. Q&A ✋

15. Let’s build the
future of data security
together!