WEBVTT
00:00:49.762 --> 00:00:55.273
Our goal is that if we do all of this work well, you start with the place where you already have the data map.
00:00:55.273 --> 00:01:07.479
Once you have the data map, you actually can see the risk really quickly and you can then you can do the good work; you can go take that risk to the Engineering Lead or the Developer and say, "Hey, there is a risk and we want to reduce it.
00:01:07.479 --> 00:01:11.271
There are four ways how we can do it, and let's work on that.
00:01:11.271 --> 00:01:19.325
" So you save all of the work, all of the time you're spending in manually building these data and you get all of that time free.
00:01:19.325 --> 00:01:25.439
And, you spend all of that time in actually reducing the risk and actually putting a privacy ticket on the Jira board, which gets shipped.
00:01:25.439 --> 00:01:27.507
So, the risk is less.
00:01:27.507 --> 00:01:28.691
Your users actually see it.
00:01:34.539 --> 00:01:36.844
Hello, I am Debra J Farber.
00:01:36.844 --> 00:01:48.930
Welcome to The Shifting Privacy Left Podcast, where we talk about embedding privacy by design and default into the engineering function to prevent privacy harms to humans, and to prevent dystopia.
00:01:48.930 --> 00:02:00.933
Each week, we'll bring you unique discussions with global privacy technologists and innovators working at the bleeding edge of privacy research and emerging technologies, standards, business models, and ecosystems.
00:02:00.933 --> 00:02:04.944
Welcome everyone to Shifting Privacy Left.
00:02:04.944 --> 00:02:08.832
I'm your Host and resident privacy guru, Debra J Farber.
00:02:08.832 --> 00:02:23.698
Today, I'm delighted to welcome my next guest, Vaibhav Antil (also known as Vee), the CEO and Co-Founder of Privado, the privacy tech platform that's bridging the privacy engineering gap, and sponsor of this podcast.
00:02:23.698 --> 00:02:25.685
Welcome, Vee!
00:02:25.784 --> 00:02:25.784
Hi Debra.
00:02:25.784 --> 00:02:26.287
Hi everyone.
00:02:27.100 --> 00:02:30.204
Before we start, I want to say a few things to you, Vee.
00:02:30.204 --> 00:02:46.149
I've had the privilege of serving as a member of Privado's Advisory Board, along with Nishant Bajaria, for the past two and a half years, advising on go-to-market messaging, thought leadership and Shifting Left evangelism; and it's been such a wonderful ride.
00:02:46.149 --> 00:02:59.459
I even remember when I was on vacation in Belgium a little over a year ago and received an email from you, Vee, asking me whether I'd consider launching a podcast that's focused on privacy engineering because Privado wants to sponsor it.
00:02:59.459 --> 00:03:01.407
I could not have been more excited.
00:03:01.407 --> 00:03:22.296
That really kicked off and started my creative journey with the Shifting Privacy Left podcast, and it's enabled me to bring this content for a growing niche audience, and I just want to take this time to publicly thank you for believing in me early on and supporting this really important educational initiative.
00:03:23.180 --> 00:03:31.590
I'm glad we could work this out and be sponsoring the podcast, and it's been amazing in creating such great content.
00:03:31.590 --> 00:03:38.439
I especially love a couple of episodes, and with so much diverse opinions and experiences.
00:03:38.439 --> 00:03:45.612
So, I learned a lot from this podcast and we've been, you know, super excited sponsoring it and continue to do so as well.
00:03:46.539 --> 00:03:47.320
Thank you so much.
00:03:47.320 --> 00:03:59.982
It really means the world to me, and I can coo and talk about how much I love Privado and you and the entire team, but I think people probably want to hear about the topic of the day; and that's several things.
00:03:59.982 --> 00:04:10.075
We're going to be talking about privacy code scanning; what 'shifting privacy left' means, especially into DevP rivO ps; and then, the importance of bridging the privacy engineering gap.
00:04:10.075 --> 00:04:21.396
So, we'll just kick things off by me asking you a little bit about Privado and how you decided to focus on code scanning for privacy and solving privacy engineering challenges.
00:04:22.841 --> 00:04:30.247
For the audience who might not be aware of Privado, Privado is a platform where privacy and engineering teams collaborate.
00:04:30.247 --> 00:04:35.953
They come together to ensure the products the companies are shipping are built with privacy from the get go.
00:04:35.953 --> 00:04:47.786
I would imagine the same role in a company is played by a privacy engineer or another privacy professional who's acting like this connective tissue or who's bridging this gap between privacy and engineering teams.
00:04:47.786 --> 00:04:58.480
I would like to think Privado is the co- pilot for this person, this Privacy Engineer or this privacy professional who's working with engineering teams, whose core job is to work with engineering teams.
00:04:59.381 --> 00:05:03.406
Essentially, my journey into privacy has been different.
00:05:03.406 --> 00:05:08.893
I mean, at least this is probably the most interesting question I ask everyone: how did you end up in privacy?
00:05:08.893 --> 00:05:11.196
And, everyone has different answers and different paths.
00:05:11.196 --> 00:05:14.983
So, my path came in from a product management role.
00:05:15.504 --> 00:05:28.396
I was a product manager for an online music streaming company, and I had seen the world where business goals as a product manage are: revenue, active users, engagement were super critical.
00:05:29.401 --> 00:05:41.874
I had this deep empathy for engineers - developers who are building these products - because they were kind of the centerpiece of shipping these features fast, which could, move the revenue numbers, the engagement numbers.
00:05:41.874 --> 00:05:44.217
They could literally do magic by building these features.
00:05:44.780 --> 00:05:53.812
While I had this experience, I ended up getting involved into a privacy project with the legal team there and kind of saw the other world - which was a privacy world.
00:05:54.172 --> 00:06:03.362
I felt that was pretty exciting, as well, because they were trying to protect the user data, do right with the user, which as a product manager, whatever you're building, you want to do.
00:06:03.362 --> 00:06:10.531
You want to make sure the promises that you are making kind of consistent and the end users' privacy is protected.
00:06:10.531 --> 00:06:13.775
That's kind of how I got introduced to privacy.
00:06:15.196 --> 00:06:15.196
When I started Privado.
00:06:15.196 --> 00:06:15.477
.
00:06:15.477 --> 00:06:15.497
.
00:06:15.497 --> 00:06:17.819
actually, the first thing I did was I tried to be like a privacy professional.
00:06:17.819 --> 00:06:26.310
I said "he first thing I'm going to do is do a data mapping project for an e-commerce company and I still remember that was.
00:06:26.310 --> 00:06:31.817
That was a sizable company, was a large e-commerce company and I probably interviewed about 80 people.
00:06:31.817 --> 00:06:49.996
That was a mix of Product Managers, Engineers, Engineering Leaders, Data Managers, Data Engineers, and the project was this crazy project to map in an Excel sheet the microservices, the data pipelines, all the products they have, and how data comes into the company and where all it goes.
00:06:49.996 --> 00:07:02.196
I still remember, I did this huge exercise - probably took like two and a half, three months - and I went to my CTO and said, "Hey, look at this sheet and this is basically around which we have to build the product.
00:07:02.956 --> 00:07:11.766
At that point of time, I was still thinking more assessments; that was kind of the way privacy teams used to get this data, which I got via interviews.
00:07:11.766 --> 00:07:27.605
But, when my CTO looked at it, he kind of had a different idea; and he basically said to me that there were probably like 30%- 40% of this information we can get by scanning the code and the rest - something we might still have to do manually - at least it'll take you that far.
00:07:28.567 --> 00:07:37.417
That led me to a realization; that was kind of our spark or our Eureka! moment where we're like, "Hey, nobody is kind of doing this at the moment.
00:07:37.860 --> 00:07:45.146
If we attack the problem from code scanning, it's a very good experience for the privacy team because they get to this information super fast.
00:07:45.146 --> 00:07:54.877
For the engineer, it's a really superior experience because when you're talking to them, the biggest problem was not understanding what a lawyer is saying.
00:07:54.877 --> 00:07:57.322
So, they get to see the same things.
00:07:57.322 --> 00:08:00.384
They get to see data in a format they understand.
00:08:00.384 --> 00:08:03.389
" And, we were early to market.
00:08:03.389 --> 00:08:04.910
So, that was exciting to me as well.
00:08:05.230 --> 00:08:15.503
So that's how privacy code scanning got started, with this huge Excel RoPA data mapping exercise; and now, of course, the vision has evolved.
00:08:17.283 --> 00:08:38.946
It started with doing RoPA, then data mapping (very, very small), and as we got some customers and started working with them, now of course, our vision is to actually be the single platform where privacy teams and engineering teams will collaborate and building a platform that engineers love and not hate, which actually gets adopted, and the privacy risk goes down.
00:08:38.946 --> 00:08:46.191
You could get more privacy issues, reviews; you can get some privacy functionalities as part of a Jira board.
00:08:46.191 --> 00:08:53.896
So, kind of enabling the privacy function, and at the same time making sure developers actually like the experience and they're engaged, as well.
00:08:53.896 --> 00:08:58.569
So, that's a little bit about how we started with code scanning and where we are in our journey.
00:08:59.480 --> 00:09:00.160
Thank you for that.
00:09:00.160 --> 00:09:01.263
That's really helpful.
00:09:02.124 --> 00:09:08.573
I know that the mantra for Privado is 'bridging the privacy engineering gap.
00:09:08.573 --> 00:09:11.497
' Can you talk a little bit more about this gap?
00:09:11.497 --> 00:09:12.480
What do you mean by it?
00:09:12.799 --> 00:09:22.349
I think this is something at least as we started, or as the initial concept of doing a code scan happened, we started speaking to privacy professionals in Europe and the U.
00:09:22.349 --> 00:09:22.668
S.
00:09:22.908 --> 00:09:31.257
I remember that we used to have slides saying where we were trying to put on some challenges that they face, and one of the things we had was 'Is engineering a black box?
00:09:31.257 --> 00:09:34.644
' Engineering is not a black box.
00:09:34.644 --> 00:09:38.069
We still know things, but there is a huge gap in our understanding.
00:09:38.069 --> 00:09:41.074
What we're trying to ask, the engineers don't understand what they tell.
00:09:41.074 --> 00:09:46.584
Sometimes we don't understand, and that's how the full concept of this privacy engineering gap came in.
00:09:46.584 --> 00:09:57.975
I also, at that point of time, read a blog post - I think it was on Adobe, where it was something like 'Privacy Principles Are from Venus; Engineering Requirements are From Mars.
00:09:57.975 --> 00:09:59.260
' S omething similar.
00:09:59.260 --> 00:10:02.764
So, a couple of things came together while we were thinking about this.
00:10:02.764 --> 00:10:07.548
But broadly, if you look at the reason on why there is a gap, I think there are three big reasons.
00:10:08.789 --> 00:10:15.096
1) I think the first big reason I've seen is there is this kind of difference in the approach of how these two functions work.
00:10:15.096 --> 00:10:19.725
So, kind of on the stakeholder level, right at the top, there's a misalignment.
00:10:19.725 --> 00:10:22.968
If you look at privacy, privacy is a very central function.
00:10:22.968 --> 00:10:23.369
Right?
00:10:23.369 --> 00:10:33.360
There's a central team who's trying to make sure use of data is consistent with the privacy promises made; or data actually gets deleted; or you're collecting less data.
00:10:33.360 --> 00:10:33.480
Right?
00:10:33.480 --> 00:10:40.789
All the nice, great privacy work, but that's done by a central team and they have the central view of things.
00:10:40.789 --> 00:10:47.360
So, look at engineering; it basically evolved from the day where it was central to super decentralized, distributed teams.
00:10:47.360 --> 00:10:47.480
Right?
00:10:47.480 --> 00:11:10.736
You have a small team of a Product Manager ,and a couple of Developers, and one Designer - sometimes just engineers who are experimenting and pushing features out, which means on one side, you want the central view of data and privacy; and on the other hand, you have this decentralization: where they are making decisions of data, architecture, tooling, decision- making on their own.
00:11:10.736 --> 00:11:15.455
So, that's the one big gap that we see is like just the way these two functions.
00:11:15.455 --> 00:11:16.177
Things are different.
00:11:16.430 --> 00:11:19.598
2) I think the second related gap here is also the speed.
00:11:19.598 --> 00:11:29.817
Engineers are kind of shipping things on a weekly, sometimes daily, basis; but, for any privacy teams, to catch up here becomes a big problem, and the tooling hasn't caught up.
00:11:29.817 --> 00:11:31.255
So, that's another conversation.
00:11:31.255 --> 00:11:36.834
So, I would say the first big problem I see is, overall, how these functions are structured are slightly different.
00:11:36.834 --> 00:11:43.176
I would imagine it's the same thing with security as well, but they have better tooling at this point to tackle all of these challenges.
00:11:43.176 --> 00:11:48.095
The second thing I see is which becomes a problem is lack of shared vocabulary.
00:11:48.095 --> 00:11:55.720
So, it's kind of like the problem is that none of these laws is descriptive; everything is written in a more principle- based way.
00:11:56.190 --> 00:12:01.038
But, when you go to the engineering team and say, "Hey, you have to delete data, it means something.
00:12:01.038 --> 00:12:03.638
Or actually, let's take a non-privacy example.
00:12:03.839 --> 00:12:08.518
As a Product Manager, I would go and say, "hey, our website has to be fast.
00:12:08.518 --> 00:12:14.575
It doesn't mean anything right now, but for an engineer it will mean something when you talk in seconds.
00:12:14.575 --> 00:12:15.514
"Okay, what does it mean?
00:12:15.514 --> 00:12:17.394
How far should the page load?
00:12:17.394 --> 00:12:18.298
What is fast?
00:12:18.298 --> 00:12:23.913
Is it 10 seconds, one second, micro second, or you can have.
00:12:23.913 --> 00:12:27.658
You can say the same thing about the specific API that, as a product manager, I own.
00:12:27.658 --> 00:12:29.377
Like you know, the response time has to be X.
00:12:29.377 --> 00:12:31.036
It has to be available for Y time.
00:12:31.036 --> 00:12:34.019
You cannot go and say our API has to be available.
00:12:34.019 --> 00:12:37.452
" there has to be some number which makes sense for the engineer.
00:12:37.990 --> 00:12:49.216
So now, once you look at this lens and go back to the privacy laws, they are not prescriptive in that sense; and hence it, becomes very difficult to operationalize privacy.
00:12:49.289 --> 00:12:52.432
3) So, you have this gap where they're not speaking the same language.
00:12:52.432 --> 00:12:57.019
The law itself is not prescriptive; and hence, it leads to the friction between the two teams.
00:12:57.019 --> 00:13:15.914
And a combination of this, I think, finally leads to a point where you might start with a very engaged privacy and engineering team; but, as engineering teams look at that, they did a bunch of assessments and questionnaire and they did not get any privacy request to implement in the product.
00:13:15.914 --> 00:13:20.296
It leads to a point where it looks, to Engineering Teams, that privacy has become a blocker.
00:13:20.296 --> 00:13:29.538
And, engineers are smart, so they try to then find ways around your DPI or PI process, which means you have now even more risk.
00:13:29.538 --> 00:13:37.336
So, I feel like these are three kind of structural things because of which there is this gap between privacy and engineering teams.
00:13:37.336 --> 00:13:45.778
100% solvable; that's what I think any privacy person working closely with engineers, or a typical privacy engineer ,is trying to do as well.
00:13:45.778 --> 00:13:48.937
That's what we, as Privado, are trying to solve, as well.
00:13:49.810 --> 00:13:50.975
That makes a lot of sense to me.
00:13:50.975 --> 00:14:07.096
One other area that I think is just very, very different between engineers and the privacy function that comes out of Legal / GRC traditionally is that lawyers don't want risk documented where there are unknowns and you don't know how to solve it.
00:14:07.096 --> 00:14:10.219
There was a time, for instance, that I was working on a major.
00:14:10.219 --> 00:14:10.990
.
00:14:10.990 --> 00:14:11.050
.
00:14:11.050 --> 00:14:22.956
a major breach had happened at a company, at a retail company; and I was one of the subcontractors working on that, and we needed to document the 'as- is' state for privacy and then come up with the 'to- be' state for privacy.
00:14:22.956 --> 00:14:32.816
So, that involved lots and lots of interviews with various types of people, including engineers and the attorneys on that case didn't want anything that was put in discovery.
00:14:32.816 --> 00:14:33.050
.
00:14:33.050 --> 00:14:33.070
.
00:14:33.070 --> 00:14:42.159
they didn't want anything that could be like "You did things wrong and now it's at trial and could be part of the discovery process, so they did not want us to document any of the risk.
00:14:42.159 --> 00:14:49.137
So, as a result, they put all of these attorneys in our meetings to make sure that those meetings were covered by privilege, right?
00:14:49.289 --> 00:14:54.278
I mean, how different is that from engineering, where it's like let's get to the meat of this problem.
00:14:54.278 --> 00:14:55.140
Let's root cause it.
00:14:55.140 --> 00:14:58.234
Let's document and make sure that we address it and fix it.
00:14:58.234 --> 00:14:58.769
Right?
00:14:58.769 --> 00:15:20.595
Right"And so those two different perspectives have been a real friction point and I think I definitely think something like Privado makes it so that the Legal and the GRC folks can have insights derived from all the great work that code scanning does and the data mapping and stuff that you do; but also give the engineers the granular data points, so that they can take action to address privacy risk.
00:15:20.595 --> 00:15:25.634
I just wanted to tell that little story because I definitely think that that's a wide gap between Engineering and Legal.
00:15:26.509 --> 00:15:31.695
However, what I've been seeing in the industry for the last couple of years is.
00:15:31.695 --> 00:15:31.695
.
00:15:31.695 --> 00:15:31.695
.
00:15:31.695 --> 00:15:45.700
one of the good things that all these regulations have done and also, I think, in general user behavior change and how much they care about privacy - is that companies have realized that this work is not going anywhere.
00:15:45.700 --> 00:15:55.980
So, while maybe the earlier approach might be to document less, I think companies slowly are realizing that they have to do the work.
00:15:55.980 --> 00:16:11.774
Once you have to do the work, everyone is, I think, reaching the same conclusion actually, is that we will need to finally take these legal policies and translate something actionable for the engineers where things happen right.
00:16:12.450 --> 00:16:17.038
That's the reason why more and more companies have now a Privacy Center and more is being launched.
00:16:17.038 --> 00:16:19.231
So, they have an open privacy center.
00:16:19.231 --> 00:16:24.076
A very simple example is to say "Hey, send an email to this person for your DSR to kickstart.
00:16:24.076 --> 00:16:35.138
So I think, as companies have realized that there's no chance that DSR is going down or there's no way that they can go away with features that have less privacy, they're now making it more formal.
00:16:35.138 --> 00:16:40.298
A consequence of that is you will see more Privacy Engineers being hired in new companies.
00:16:40.298 --> 00:16:44.055
Companies with existing Privacy Engineers are starting up more, as well.
00:16:44.055 --> 00:16:55.534
So, I do think that's a big trend shift which has happened in industries that companies have come to that conclusion, and they are now staffing up, building processes, and buying tooling for the exact same reasons.
00:16:56.518 --> 00:16:56.819
Awesome.
00:16:56.819 --> 00:17:02.774
So, how can engineers provide visibility into the personal data that applications are collecting and using?
00:17:03.110 --> 00:17:07.441
Unfortunately, this is kind of a very tough problem.
00:17:07.441 --> 00:17:09.474
Again, let me take a step back.
00:17:09.474 --> 00:17:27.681
If you talk in generalities - nothing related to personal data - I think one thing that people have been trying to do, or were trying to create another kind of documentation, is network diagram, architecture diagrams; which a lot of engineers create as part of their requirement.
00:17:27.681 --> 00:17:32.557
Maybe it's part of their company's policy or they have to do it because it's a sales facing document.
00:17:32.557 --> 00:17:43.355
It's very difficult to even get that updated, which has very high motivation for the engineering teams to maintain or accurate version of it, right, they'll see like all those documentation get outdated as well.
00:17:43.355 --> 00:17:45.517
The same is true for their service names.
00:17:45.517 --> 00:17:45.738
Right?
00:17:45.950 --> 00:18:06.276
Nobody has a clear idea of "Okay, I have built this product, which is basically this backend microservice," and then over time, a lot of other components in engineering starts to interact, like your website dashboard and some other backend systems, and then someone makes a change in this specific component and 10 things break on each side.
00:18:06.276 --> 00:18:14.838
Essentially, I mean, if I take a step back and look at it, documentation of any kind is tough when things are decentralized and are changing fast.
00:18:15.230 --> 00:18:25.891
That's where the engineers operate, so they have a product or an application which was built by let's say, if you start to do it today, built by some engineers who are not in the company.
00:18:25.891 --> 00:18:33.919
It probably has hundreds of thousands to millions of lines of code, which means there's no single person who can actually tell you what is in there.
00:18:33.919 --> 00:18:37.039
What they can do, is they can at least give you a good starting point.
00:18:37.039 --> 00:18:38.957
I think engineers can give you a good starting point.
00:18:38.957 --> 00:18:47.217
The biggest gap I see there is what a privacy person means 'personal data' is; the definition is not the same for engineers.
00:18:47.217 --> 00:18:56.396
They might be thinking PII, like email address; and as you start to have those conversations, they will give you more information like "oh yeah, we do have clickstream data that we collect.
00:18:56.396 --> 00:18:58.277
Oh yeah, we do collect audit data.
00:18:58.277 --> 00:18:59.315
Is that even personal data?
00:18:59.315 --> 00:19:01.959
So I think it is super challenging.
00:19:01.959 --> 00:19:08.579
But current engineers can give you at least a starting point on what data are they collecting and using.
00:19:08.579 --> 00:19:15.976
Directionally, you will get the right answer, but an accurate representation, depending on what stage you are.
00:19:15.976 --> 00:19:15.976
.
00:19:15.976 --> 00:19:15.976
.
00:19:15.976 --> 00:19:24.336
if you are at a decent stage; which means your company has been there for a while; which means there are multiple people who built the product; and which means it'll be super complex.
00:19:25.329 --> 00:19:27.778
At this stage, I would recommend to do more automation.
00:19:27.778 --> 00:19:29.676
One type of automation is doing code scanning.
00:19:29.676 --> 00:19:38.451
Another automation, or actually, even if you don't want to automate, you can just look at your product, go to the website, try to use it and say, "Oh, I see one data element which is missing, I see another.
00:19:38.451 --> 00:19:42.038
" Do it in a session, and you will actually uncover even more data elements.
00:19:42.038 --> 00:19:56.278
So, a session where you can go through the product and then ask questions will give you more data elements than just sending an Excel sheet or assessment; and ideally, what you want to do is generate these documentations from automated tools.
00:19:56.278 --> 00:20:07.216
I believe privacy code scanning - of course I'm biased - is one of the better ways to do that because it's generating the document from the source of truth, which is the code; and it actually enables engineers.
00:20:09.732 --> 00:20:14.598
In fact, to that point, the Google Play Store came up with this requirement to generate Play Store Data Safety Report.
00:20:14.598 --> 00:20:23.051
We actually open sourced, and made available, a free tool - it is still available - called Play Store Data Safety Generator; and what it does.
00:20:23.051 --> 00:20:23.373
.
00:20:23.373 --> 00:20:35.259
.(and it got downloaded, I think, thousands of times) where Android engineers came in, downloaded the app, ran a scan on their Android application, and it prefilled nearly 80% of the Play Store Data Safety Report.
00:20:36.091 --> 00:20:39.353
At the end of the day, they filled out the rest of the stuff, downloaded it, and put it there.
00:20:39.353 --> 00:20:47.317
So, that's another example of a code scanning approach, where you're using some automation to generate these documents actually help.
00:20:47.317 --> 00:20:51.538
So, again - it's a long answer, but to summarize, use automated tools.
00:20:51.538 --> 00:20:52.976
Your engineers will thank you for that.
00:20:52.976 --> 00:20:54.855
If not, do a session with them.
00:20:54.855 --> 00:20:55.719
That works as well.
00:20:55.719 --> 00:20:58.337
I did that when I was trying to do it the first time.
00:20:59.652 --> 00:21:03.478
That's definitely is easier to do when you just have maybe one product or team.
00:21:03.478 --> 00:21:09.235
But, if you're like a privacy person that comes in as a consultant, that's like "oOkay, we've never done this before.
00:21:09.235 --> 00:21:12.098
Go and get data maps of all our products.
00:21:12.098 --> 00:21:17.798
Have all of these interviews"- I mean something I've done before; it is a massive, massive effort.
00:21:17.798 --> 00:21:20.878
So, I definitely think automation comes in handily that way.
00:21:21.711 --> 00:21:27.514
Just to add one thing - one of our core motivations is, at the end of the day, as privacy professionals,
00:21:27.976 --> 00:21:37.576
as privacy engineers, you really want to go in and build something in the product or remove certain flows which should not be there in the product.
00:21:37.630 --> 00:21:48.856
So, you want to reduce privacy risk, and you want to shift privacy features; but, the majority of the work is spent in collecting data, is asking people questions, is building this data map, which I feel should not be there.
00:21:49.210 --> 00:22:07.713
Our goal is that, if we do all of this work well, you start with the place where you already have the data map; and once you have the data map, you actually can see the risk really quickly and you can then do the good work, which is, you can go take that risk to the Engineering Lead or the Developer and say, "hHey, there is a risk and we want to reduce it.
00:22:07.713 --> 00:22:19.434
There are four things how we can do it and let's work on that; but you save all of the work, all of the time you are spending in manually building these data maps, and you get all of that time free.
00:22:19.434 --> 00:22:26.115
You spend all of that time in actually reducing the risk and actually putting a privacy ticket on the JIRA board, which gets shipped.
00:22:26.115 --> 00:22:27.675
So, you know the risk is less.
00:22:27.675 --> 00:22:28.855
Your users actually see it.
00:22:28.855 --> 00:22:40.682
" I would say that's the strongest argument I have personally seen for automation is you you free up time which can be used to do better things, for things which can impact the user privacy immediately.
00:22:42.207 --> 00:22:43.651
Exactly, I totally agree.
00:22:43.651 --> 00:22:51.217
In fact, I was going to ask you, why is shifting privacy left into DevOps important to you, but I think you kind of summed up some of the reasons why.
00:22:51.217 --> 00:22:53.951
I want to give you the opportunity to add anything.
00:22:53.951 --> 00:22:53.951
.
00:22:53.951 --> 00:22:53.951
.
00:22:55.745 --> 00:22:58.803
to answer the question holistically: why is shifting left important?
00:22:58.803 --> 00:23:02.913
You could shift left into design, shift left into architecture.
00:23:02.913 --> 00:23:07.813
Privado focuses on DevOps, so I wanted to highlight that and get an understanding from you.
00:23:07.985 --> 00:23:08.267
Yeah, sure.
00:23:08.267 --> 00:23:15.480
I think one of the great things that has happened in engineering is people have moved to this agile development.
00:23:15.480 --> 00:23:22.386
A part of it is also continuous software delivery, which means you are continuously shipping features out.
00:23:22.386 --> 00:23:23.990
You're fixing bugs super fast.
00:23:23.990 --> 00:23:33.114
For the end user, it's amazing because, let's say, our own customer, we find a bug today; we can literally fix the bug and, in the next 10 minutes, it gets deployed.
00:23:33.114 --> 00:23:42.871
So, companies have built this amazing tooling and infrastructure for engineers where they can build features, release them, and they go live at the customer level super fast.
00:23:43.030 --> 00:23:46.567
Because of cloud and best DevOps practices, it's possible.
00:23:46.827 --> 00:23:49.135
So, a lot of investment has gone into this.
00:23:49.135 --> 00:23:56.441
How can we actually build fast, ship fast so our end users can get to see these features fast?
00:23:56.441 --> 00:24:06.076
Once you wear this hat and say, "okay, my company is going to change things super fast, right, they're going to change things every week, things are going to get shipped every second.
00:24:06.076 --> 00:24:20.586
" Then, you can't have a privacy mindset, which is thinking weeks or months, which is typically like a privacy impact assessment or a data protection impact assessment At the design stage you do want to spend time because the feature has not started to be developed.
00:24:20.586 --> 00:24:24.015
So, you can spend that time and do technical privacy reviews, etc.
00:24:24.015 --> 00:24:29.749
But, once all of that is done, there is huge work which doesn't come into that regular design cycle.
00:24:29.749 --> 00:24:42.267
It goes through this continuous software delivery model where in engineers are writing code, they're pushing code, things don't remain the same from a design to an implementation phase, and that's basically a missing gap in the current privacy programs.
00:24:42.267 --> 00:24:49.048
You don't really have an oversight there, and that's what shifting privacy into the DevOps process means.
00:24:49.048 --> 00:25:08.426
It means, as a privacy professional, you have a privacy check as part of this DevOps cycle, which ensures the new code changes which are happening, the configuration changes which are happening, a new database being created, a new third- party being added, a new pixel being added to your website, is going through this privacy check.
00:25:08.426 --> 00:25:14.871
And then, this privacy check is looking at it and saying, "okay, this is a high risk privacy issue, we have to block it.
00:25:14.871 --> 00:25:17.116
It needs to be fixed before it goes live.
00:25:17.116 --> 00:25:22.287
Or it's a low risk, we can let it go live, but it creates a ticket for the engineer to fix later.
00:25:22.647 --> 00:25:32.050
Shifting privacy left, or this full DevPrivOps is kind of a methodology where privacy is going and saying, "hey, we have this, we shifted extremely left to the design phase.
00:25:32.050 --> 00:25:34.277
We're right at the inception of a new feature.
00:25:34.277 --> 00:25:42.678
We are doing privacy reviews and thinking about new products from a privacy perspective, both on the legal side on and on the technical privacy side.
00:25:42.678 --> 00:25:46.694
So they're going from that to saying, okay, but we also need to solve things at scale.
00:25:46.694 --> 00:25:58.913
We also need to acknowledge the fact that our engineering workflows are at a daily, weekly speed and we need to have something on the privacy side which matches that as well.
00:25:58.913 --> 00:25:58.913
"
00:25:59.433 --> 00:26:19.114
Another way that I can articulate it how a Privacy Engineering Leader told me - the way they like to think about this DevPrivOps or shifting left is a lightweight, consistent governance; wherein, instead of looking at 90 things, you look at 6 things and the rest of the 84 things are automatically checked.
00:26:19.114 --> 00:26:24.094
So, it's lightweight; it's not adding a lot of time or a lot of commitment for the developers.
00:26:24.094 --> 00:26:24.916
It's consistent.
00:26:24.916 --> 00:26:33.257
So, it checks all the time and so you are assured of whatever is going out to production, to your end user, as less privacy risk.
00:26:33.257 --> 00:26:36.387
That's the philosophy of DevPrivOps or DevOps.
00:26:36.387 --> 00:26:45.796
Yeah, shifting left just means go earlier, find things earlier so there are fewer things that you're finding in your products, which have gone live.
00:26:45.997 --> 00:26:46.277
Ideally.
00:26:46.277 --> 00:26:46.706
.
00:26:46.706 --> 00:26:46.726
.
00:26:46.866 --> 00:26:54.678
the most common one I've seen with our customers, which I never thought would be, is they find these cookies on their website.
00:26:54.678 --> 00:27:50.217
You would imagine that it would be solved, but if they have a large front end team, they'll find cookies on their website that are first- party cookies, and they're not easy to find who actually added that.
00:27:50.217 --> 00:27:50.706
Right?
00:27:50.706 --> 00:27:56.571
Because there could be 20- 30 front end engineers working on the same website or same dashboard.
00:27:56.571 --> 00:27:58.821
So, third- party cookies are easy to track.
00:27:58.821 --> 00:28:03.936
It's generally the marketing team or analytics team, but first- party cookies could be some part of the engineering team.
00:28:03.936 --> 00:28:17.696
So, that could mean the moment an engineer decides to add a cookie, it creates an issue and alert for the engineer to say "you have to onboard it to our CMP" - whatever consent management platform you use - and then, it gets shipped.
00:28:17.696 --> 00:28:24.076
So, you're not chasing the entire 40 member team when you discover it later in your cookie scan, when it hits actually production.
00:28:24.278 --> 00:28:27.500
That's shifting left in the entire DevOps world.
00:28:28.786 --> 00:28:29.127
Awesome.
00:28:29.127 --> 00:28:32.073
Before code is ever shipped to production.
00:28:32.073 --> 00:28:35.750
So, 'fix it before it's in production' is a great mantra, in my opinion.
00:28:35.750 --> 00:28:42.132
Let's talk a little bit about privacy code scanning, since that's the crux of what Privado provides.
00:28:42.132 --> 00:28:49.342
Let's start with what is a privacy code scanner and how does it differ from traditional static code analysis tools in security?
00:28:49.342 --> 00:28:56.932
And maybe, it's also a good time to bring up the difference between static code analysis and dynamic code analysis to differentiate from what you don't do.
00:28:57.786 --> 00:28:58.147
Yeah, sure.
00:28:58.147 --> 00:29:01.013
Think of a privacy code scanning as.
00:29:01.013 --> 00:29:01.914
.
00:29:01.914 --> 00:29:06.692
.the technology itself of scanning the code to look at patterns is super old.
00:29:06.752 --> 00:29:26.215
I t started with saying, "okay, our developer is writing code in a way which is consistent with our coding practices" to then, you know, looking for license compliance issues in open source packages, to the security scanning tools that you set, which is looking at, "Hey, do we have code written that a hacker can attack?
00:29:26.215 --> 00:29:27.240
You know, like, can they?
00:29:27.240 --> 00:29:31.999
Can they use this weakness in our application code to attack and get some data out?
00:29:31.999 --> 00:29:34.046
And so the concept is the same.
00:29:34.046 --> 00:29:34.668
Where you are.
00:29:34.668 --> 00:29:34.708
.
00:29:34.708 --> 00:29:39.749
.I mean, the technology is looking at the code, scanning it and then giving you out some information.
00:29:39.749 --> 00:29:44.990
In that way, the approach - that technology - is old; we just applied it for privacy.
00:29:47.925 --> 00:29:48.005
What it really means is.
00:29:48.005 --> 00:29:48.407
.
00:29:48.407 --> 00:29:48.606
.
00:29:48.606 --> 00:29:55.211
essentially, a privacy code scanner is going to scan your code of anything your engineer has built and build a data flow graph out of it.
00:29:55.211 --> 00:29:57.522
It has to basically give you a couple of data points.
00:29:57.522 --> 00:30:00.515
It has to tell you what data is coming into this application.
00:30:00.515 --> 00:30:02.081
What's coming in?
00:30:02.081 --> 00:30:04.068
What happens with that once it comes in?
00:30:04.068 --> 00:30:04.952
Where it flows?
00:30:04.952 --> 00:30:16.523
Where is it going out - which means it could go out to a database, it could go out to a cookie, it could go out to a third party, it could go to your own internal infrastructure, your own internal backend service wherever it is going.
00:30:16.523 --> 00:30:16.523
.
00:30:17.887 --> 00:30:35.026
The crux of a privacy code scanner is to build a data flow graph, or a data flow diagram, of your specific application that you're scanning and with the focus on all life cycle: collection, storage, sharing, logging, transformation, processing, all of it.
00:30:35.026 --> 00:30:41.666
Once you have this basic graph done, then on top of it, you can do a couple of interesting things.
00:30:41.666 --> 00:30:45.077
Once you have that, you can generate a RoPA report.
00:30:45.077 --> 00:30:48.970
You can build a data flow diagram for your threat modeling.
00:30:48.970 --> 00:31:06.673
Once you have all these flows, then you can leverage something like a policy or a rule engine to say, "show me all applications where sensitive data is being shared with third- parties," or show me all applications where we have a pixel, or show me all applications where there are cookies Any of these things.
00:31:06.673 --> 00:31:08.907
You can do so in a simplest way.
00:31:08.927 --> 00:31:24.797
Privacy code scanning - think of it as something which will scan the code of the application and build a data flow graph or a diagram out of it, focusing on specific lifec ycle cycle of data coming in, which is collection, and data going out, which could be sharing, storage, logging, processing in general.
00:31:24.797 --> 00:31:37.596
Once you have that, it should enable you to do all the core privacy use cases of RoPA documentation, privacy by design, finding privacy issues, and so forth.
00:31:37.999 --> 00:31:41.880
The main difference is that a security code scanner will not care about all of this.
00:31:41.880 --> 00:31:46.738
They don't care if the application is going to process personal data.
00:31:46.738 --> 00:31:49.661
If it has a security vulnerability, it has a security vulnerability.
00:31:49.661 --> 00:31:53.101
On the other hand, we do care about that; we only care about that.
00:31:53.161 --> 00:31:55.471
We don't care about if it has a security vulnerability.
00:31:55.471 --> 00:31:59.473
We only care about whether we accurately build this data flow graph.
00:32:00.302 --> 00:32:01.365
That is really helpful.
00:32:01.365 --> 00:32:12.590
I think it would be even more helpful to the audience if you could differentiate how does privacy code scanning and the data mapping capabilities of Privado.
00:32:12.590 --> 00:32:13.441
.
00:32:13.441 --> 00:32:13.441
.
00:32:13.441 --> 00:32:23.383
how is that completely different (because, I know that it is) from the traditional tools out there that do personal data discovery, correlation, data mapping - companies like BigID, Secuvy.
00:32:23.383 --> 00:32:24.445
ai, Securiti.
00:32:24.726 --> 00:32:26.971
ai, companies like that.
00:32:27.071 --> 00:32:27.312
Yeah.
00:32:27.312 --> 00:32:32.086
I would say, if you look at data discovery in general, it's basically discovering data at rest.
00:32:32.086 --> 00:32:46.484
What you're trying to say is, "hey, as a company, we've grown; and we continuously collected data, and then we kept on storing it, and now we don't have a good handle of where all of that is stored; which, from a security perspective, is important to secure the data.
00:32:46.484 --> 00:32:51.765
From a privacy perspective, it's important because you need to delete the data pieces, do retention, et cetera.
00:32:51.765 --> 00:33:08.849
So, a data discovery tool focuses on how quickly, at scale, with a good performance, I can go in and tell you where personal data is, in which data store, in which file, in which SaaS app.
00:33:08.849 --> 00:33:11.006
So, that's looking at data at rest.
00:33:11.006 --> 00:33:23.148
Now, the reason you need code scanning, even if you have a data discovery tool ( especially if you have a data discovery tool) is that a data discovery tool only gives you the picture of what data you have at rest.
00:33:23.148 --> 00:33:25.968
But, privacy is all about data use.
00:33:25.968 --> 00:33:29.804
It's about did you collect more data than you were supposed to?
00:33:29.804 --> 00:33:31.646
How did this data get used?
00:33:31.646 --> 00:33:37.067
A famous example was, a company was not fined because their phone number were breached or leaked.
00:33:37.067 --> 00:33:42.327
The company was fined because they collected phone numbers for authentication purposes, but were using them for advertising.
00:33:42.327 --> 00:33:47.331
That picture of how data gets used is actually in the code.
00:33:47.331 --> 00:33:51.425
It's actually in how you build a product, how you build an application.
00:33:51.425 --> 00:33:52.143
It's as simple as that.
00:33:52.163 --> 00:33:59.746
When you're doing a PIA, you're doing a PIA, not on the database; you're doing a PIA on a processing activity or a product function, or a product, or an application.
00:33:59.746 --> 00:34:07.245
We are doing it because you know privacy is about the full use of data - the collection point, the sharing point - and storage is one part of it.
00:34:07.245 --> 00:34:13.766
So, that's why you need to scan the code to get an automated understanding of how my data gets used.
00:34:13.766 --> 00:34:19.326
"Okay, I know it's in this database, but do you know which two products are connected to this one database?
00:34:19.326 --> 00:34:22.782
Do you know how that gets shared to a third party eventually?
00:34:22.782 --> 00:34:31.590
All of that information is written in code by engineers, version controlled and maintained, and that's why you need a code scanning solution.
00:34:31.590 --> 00:34:46.166
That's one answer, which is more around looking at the lifecycle of data, and their discovery solution only captures storage, whereas code scanning solution captures the complete lifecycle, especially if you're looking at engineering and products.
00:34:46.679 --> 00:34:54.085
The second argument on where these tools differ is the data discovery tools are looking at things when they've already entered your system.
00:34:54.085 --> 00:34:56.288
So, they've already collected the data.
00:34:56.288 --> 00:34:57.545
It's already in your system.
00:34:57.545 --> 00:35:03.668
That's when you're discovering "okay, yeah, now we have a new database which has these many data elements, right?
00:35:03.668 --> 00:35:04.844
Or we have this new file.
00:35:04.844 --> 00:35:17.429
" the code scanning solution - because they're super early in the lifecycle; we must shift left - this is when engineers just write in code to collect phone numbers for the first time, or precise location for the first time.
00:35:17.429 --> 00:35:21.927
You have not really pushed this to your production, which means it's not yet live.
00:35:21.927 --> 00:35:24.047
No customer data has ever flowed through that code.
00:35:24.500 --> 00:35:37.166
You can actually scan and discover all of these things at that time, which means if you want to get out of the cycle of a technical privacy debt, as you move left, through code scanning you can prevent some of these things.
00:35:37.559 --> 00:35:48.608
You can basically ensure that if you were not supposed to collect precise location, you're not collecting it, which means you have to do less scanning on the right side, where data discovery tools sit.
00:35:48.608 --> 00:35:52.465
You can also enforce better privacy standards, privacy engineering standards.
00:35:52.465 --> 00:36:03.485
When someone is creating a database, attaching it to your application code if that database table has sensitive data along with general identifiers, you can tell them not to do that.
00:36:03.485 --> 00:36:08.827
If they are going to share data with third parties, that's something you can catch early and fix as well.
00:36:08.827 --> 00:36:11.106
I would say these are the two main differences.
00:36:11.106 --> 00:36:19.887
One is from a coverage perspective - you do want to get clear line of sight into data sharing and data use, which is only available in the code.
00:36:19.887 --> 00:36:21.987
It's not available at the data storage layer.
00:36:21.987 --> 00:36:31.429
And I would say, second is moving left to fix and prevent things - find, fix, and prevent things rather than fire-fighting on the data side only.
00:36:31.429 --> 00:36:37.467
That's how privacy code scanning approach differs from a classic data discovery approach.
00:36:39.000 --> 00:36:41.889
I also want to highlight something.
00:36:41.889 --> 00:36:50.865
I am both an Advisor to Privado as well as an advisor to Secuvy because I definitely think that they are separate products that address separate issues.
00:36:50.865 --> 00:36:55.728
For companies today that are like w"We need to know where our personal data is.
00:36:55.728 --> 00:37:01.704
This wasn't a thing we needed to do and, in the big data era of collect everything, figure out a use for it later.
00:37:01.704 --> 00:37:04.539
It's sprawled across our environment.
00:37:04.539 --> 00:37:07.450
It's structured, unstructured, semi-structured data stores.
00:37:07.701 --> 00:37:08.605
Where is it?
00:37:08.605 --> 00:37:12.450
Because you can't protect any personal data if you don't know where it is.
00:37:12.450 --> 00:37:14.327
You can't delete it if you don't know where it is.
00:37:14.327 --> 00:37:19.505
You can't provide it to somebody and show them what you've collected about them if you don't know where it is.
00:37:19.505 --> 00:37:28.588
And so, I think it is absolutely important for companies in that space to use a data discovery, correlation, classification mapping tool.
00:37:29.059 --> 00:37:37.523
But, as you said, I want to see a world where everyone's using a privacy code scanner like Privado's, where you get your engineering best practices put in place.
00:37:37.523 --> 00:37:44.769
You embed privacy into the software development lifecycle, which is not the BigID, Secuvy, Securiti.
00:37:44.769 --> 00:37:46.567
ai tools are doing.
00:37:46.567 --> 00:37:52.690
They're looking more at the personal data lifecycle rather than embedding into the software development lifecycle.
00:37:52.690 --> 00:38:01.864
They are very different tools and I definitely think companies can use both, obviously depending on the maturity and whether or not you have the right resources to manage these tools.
00:38:01.864 --> 00:38:07.666
How does privacy code scanning enable engineering teams to stay compliant with new laws?
00:38:07.666 --> 00:38:21.126
I know you mentioned that before, but let's take, for instance, my state - Washington State's My Health My Data Act, which grants consumers the right to access, delete, and withdraw consent from the collection, sharing and processing of their health data.
00:38:21.287 --> 00:38:22.340
Yeah, absolutely.
00:38:22.340 --> 00:38:32.686
In fact, the My Health My Data Act is a classic example of where you do need to move to code to actually comply with the law, because it focuses on a couple of things.
00:38:32.686 --> 00:38:38.403
One of the main things it does focus on is use of data, like purpose of why you've collected it and how you're using it.
00:38:38.403 --> 00:38:40.346
So that is one.
00:38:40.346 --> 00:38:45.927
Sharing of health data is the most critical part there, and both of these things are in the code.
00:38:45.927 --> 00:38:47.465
So, take a health app.
00:38:47.465 --> 00:38:52.456
The first thing they would want for them to comply as a privacy or an engineering team.
00:38:52.456 --> 00:38:52.456
.
00:38:52.456 --> 00:38:52.456
.
00:38:52.961 --> 00:38:57.907
they will be asked "what health data you collect and who you share it with and how you use it.
00:38:57.907 --> 00:39:01.088
With Privado, you can basically connect in five minutes.
00:39:01.088 --> 00:39:22.684
We'll run a scan on all your code repositories and give you one single view of all the health data you're collecting; where that health data is flowing; and which products are using this health data, which means it solves all the three use cases of My health My - you you can, to do your consumers, consumers confidently say"This this is the health data that we collect, this is who we share it with.
00:39:22.684 --> 00:39:24.184
These are the service providers.
00:39:24.184 --> 00:39:33.891
If you are sharing it for any advertising reason, then you have to take authorization; and this is how all use cases we are using the health data for.
00:39:33.891 --> 00:39:35.224
So that's number one.
00:39:35.224 --> 00:39:36.766
So, you get to compliance faster.
00:39:38.364 --> 00:39:41.927
As I said, you don't have to spend months in figuring out this information.
00:39:41.927 --> 00:39:45.708
You can fix things rather remove certain health data flows.
00:39:46.139 --> 00:40:00.349
I think the second most important thing with the My Health My Data Washington Act is, if I remember correctly, there's a class action lawsuit, which means there is a very high onus on companies to prevent privacy issues from going to production.
00:40:00.590 --> 00:40:07.590
This means you do need a policy in your DevOps system, in your SDLC, looking for privacy issues.
00:40:07.639 --> 00:40:30.766
So, something needs to check for saying, "Hey, I pushed this code, I was using Google Analytics, but then I, incidentally or accidentally, actually started sending health data to Google Analytics because the page name has it or the search query had it, or I was intending to send only the user ID, but I sent this full object which has the health details as well.
00:40:30.766 --> 00:40:32.030
That's the second part.
00:40:32.030 --> 00:40:35.887
So one is like the initial compliance, which is your data maps, faster.
00:40:35.887 --> 00:40:40.903
You get the entire picture of health data collection, sharing ,and use - faster.
00:40:40.903 --> 00:40:56.144
And, second is guardrails - having these automated privacy checks for My Health My Data on behalf of privacy teams, which are not only looking for issues, but also providing a guidance to engineers on what to do right when they make a change.
00:40:56.144 --> 00:41:03.376
This will help you scale your program and actually, not only comply, but also remain in compliance with these laws.
00:41:04.642 --> 00:41:05.003
Awesome.
00:41:05.003 --> 00:41:05.826
Thank you for that.
00:41:05.826 --> 00:41:06.769
That's illustrative.
00:41:06.769 --> 00:41:13.307
All right, I want to talk a little bit about the future of Privado and just also privacy engineering education for a little bit.
00:41:13.307 --> 00:41:25.191
One of the things that really impresses me about Privado is that the founders focus on educating the next wave of privacy engineers is so important.
00:41:25.191 --> 00:41:47.451
Besides sponsoring this podcast, Robert Bateman's 'Privacy Corner', and, Vee, your own webinar series on privacy engineering, Privado recently made available a free Technical Privacy Masterclass hosted by Nishant Bhajaria, Privado's Advisor and Author of the seminal work 'Data Privacy: A Run Book for Engineers.
00:41:47.451 --> 00:41:50.387
' Can you tell us a little bit about this masterclass?
00:41:50.387 --> 00:41:51.744
Who was it designed for?
00:41:51.744 --> 00:41:53.724
What topics does it cover?
00:41:53.724 --> 00:41:55.664
How long does it take to complete?
00:41:55.664 --> 00:41:56.228
that kind of thing?
00:41:56.400 --> 00:42:02.621
That was such a fun project to build this course with Nishant on technical privacy.
00:42:02.842 --> 00:42:04.648
Again, the motivation for us was.
00:42:04.648 --> 00:42:04.921
.
00:42:04.921 --> 00:42:07.017
.it was also like an inward- facing motivation for us.
00:42:07.017 --> 00:42:35.369
It was like, "Hey, as we've been speaking and working with our customers, we end up working with a lot of technical privacy leaders and privacy engineers;" and some people have been in industry for a while, some are entering and I was like, is there some space where technical privacy leaders or privacy engineers can come together, Learn, talk, care, and that led to this one- by- one or multiple kind of initiatives, like starting with sponsoring a podcast.
00:42:35.369 --> 00:42:44.471
Then, as we went through that feedback cycle, working on this course, launching a community, doing our own webinars around this as well.
00:42:44.599 --> 00:42:49.152
It's been a great learning experience because I personally get to learn a lot doing.
00:42:49.152 --> 00:42:49.380
.
00:42:49.380 --> 00:42:55.128
.not just the masterclass but looking at questions in each webinar, listening to your podcast as well.
00:42:55.128 --> 00:42:55.327
Right?
00:42:55.327 --> 00:43:01.412
Specifically, on the masterclass, I mean it's for anyone who's working in a technology company.
00:43:01.633 --> 00:43:07.351
So, basically, we built it in such a way that it talks about why engineering is different.
00:43:07.351 --> 00:43:16.907
If you are in a tech company that has a lot of engineers, it starts with explaining how engineering has evolved and why it is different - kind of the same thing we were talking about initially.
00:43:17.440 --> 00:43:23.688
Then, it goes into how you can build a privacy program, which is kind of more aligned to how your engineering practices are.
00:43:23.709 --> 00:43:26.567
So, it's more proactive it actually kind of works.
00:43:26.567 --> 00:43:37.347
Then, we also went a little deep into how can you build a privacy tooling; how can you build your own DSAR; how can you buy or build a data discovery solution; and then, finally, goes into KPIs.
00:43:37.347 --> 00:43:41.590
It also has a nice bonus episode with Nishant's journey into privacy engineering.
00:43:41.590 --> 00:43:51.090
So, our core motivation was to help people who are entering or who are already, I would say are, 'Unofficial Privacy Engineers,' who are still doing the work.
00:43:51.090 --> 00:43:56.264
So, they can get a resource to begin with, and they can learn and enter the field.
00:43:56.264 --> 00:43:58.730
That was our motivation to do it.
00:43:58.730 --> 00:44:07.769
It's been a great experience launching this because we've got such an amazing feedback, both positive and also critical, on where we can improve.
00:44:07.769 --> 00:44:16.349
We have a lot of data points on the next modules we want to add and the version 2, how it could change, as well.
00:44:16.349 --> 00:44:19.688
But yeah, it was such a fun project to work on as well.
00:44:20.940 --> 00:44:31.351
I've been in privacy for over 18 years and even I learned new things from Nishant's perspective on how to approach implementing some of these solutions.
00:44:31.351 --> 00:44:37.392
I absolutely think - this is the best technical privacy class I've ever come across.
00:44:37.392 --> 00:44:38.945
I think it's excellent.
00:44:38.945 --> 00:44:41.809
I'm not raving about it simply because I'm a Privado Advisor.
00:44:41.809 --> 00:44:44.927
I think it's something that can be used by, well.
00:44:44.927 --> 00:44:45.288
.
00:44:45.288 --> 00:44:48.427
.anyone in privacy can take it; it's certainly aimed at technical folks.
00:44:48.840 --> 00:44:51.026
It would be great for engineering teams that are upskilling on privacy to take this.
00:44:51.026 --> 00:45:06.970
It would be great for current Privacy Engineering Managers to take this and take it with their teams, and maybe something they do as they talk about increasing their skills over the year, and being able to show the certificate that they've completed it.
00:45:06.970 --> 00:45:07.943
How long is it?
00:45:07.943 --> 00:45:09.387
I know I took it, but I wasn't sure.
00:45:09.387 --> 00:45:10.905
Is it like around 3 hours long?
00:45:11.420 --> 00:45:16.012
Yeah, roughly about anywhere from 2 - 3 hours is probably the content.
00:45:16.420 --> 00:45:18.726
It's somewhere between 2 - 3 hours.
00:45:18.887 --> 00:45:19.610
It's not a lot.
00:45:20.001 --> 00:45:21.985
This is kind of, as you said.
00:45:21.985 --> 00:45:23.269
.
00:45:23.269 --> 00:45:28.831
.probably like one third of people who attend our privacy engineering webinars are people who are trying to enter the field.
00:45:28.831 --> 00:45:30.845
For them, this is like a good primer.
00:45:31.467 --> 00:45:34.023
Some of them are actually software engineers who built.
00:45:34.023 --> 00:45:34.806
.
00:45:34.806 --> 00:45:50.170
.they literally have built a DSAR system in the company from ground up, like the full infrastructure; and now, they can actually learn the other parts of privacy, which is not just the tooling, but the wires in the house and you know how to think about it - a privacy program, KPIs, and stuff like that.
00:45:50.170 --> 00:45:57.992
So, yeah, that is the kind of audience that we have and, two to three hours - not a lot of effort, but a lot of learnings for sure.
00:45:58.800 --> 00:46:03.972
Oh, so much impact! So much wisdom dispensed by Nishant in that amount of time.
00:46:03.972 --> 00:46:06.526
So, it really does feel like a masterclass.
00:46:07.068 --> 00:46:10.528
You could be talking to experts, as well, in it.
00:46:10.528 --> 00:46:21.291
He's clearly talking in a way where both experts can step back and get more of a holistic perspective about what their approach is; but newbies to the field could also pick up those best practices immediately.
00:46:21.291 --> 00:46:22.766
So, it really is good.
00:46:22.766 --> 00:46:29.568
I'm going to put a link to it in the show notes so that anyone can check it out; and, remember it's free, so there's really no negative here.
00:46:29.568 --> 00:46:32.809
If you have the will, then Privado's provided the resource.
00:46:32.809 --> 00:46:35.287
I do want to know if you have numbers?
00:46:35.287 --> 00:46:36.289
How long has it been out now?
00:46:36.289 --> 00:46:37.144
Like a month or two?
00:46:37.581 --> 00:46:39.347
How many people have completed the course so far?
00:46:39.740 --> 00:46:47.099
About that - we are inching towards getting 1000 enrollments to the course.
00:46:47.099 --> 00:46:49.579
So, yeah, it's organically grown a lot.
00:46:49.579 --> 00:47:00.599
I mean, again, I'm super thankful to people who took the course, posted on LinkedIn, and gave good feedback because that encourages more people to take the course and then, you know, more people can learn about it.
00:47:00.599 --> 00:47:02.305
Because it's successful.
00:47:02.305 --> 00:47:02.566
.
00:47:02.566 --> 00:47:07.970
.again, as I said, the next version of it - at least for the people have taken it - we are going to go deeper.
00:47:07.970 --> 00:47:22.686
Like one is Technical Privacy Review - something that I'm really looking forward to create with different people, along with Nishant, something very specific which goes into, OK, how do you do a review?
00:47:22.686 --> 00:47:23.680
How should you design it?
00:47:23.680 --> 00:47:25.166
What should the KPIs be?
00:47:25.166 --> 00:47:31.159
" So, once we have this base where people have taken it, I think the next ones are going to be more in there.
00:47:31.159 --> 00:47:33.864
Ai governance is another one we are thinking about as well.
00:47:34.967 --> 00:47:35.791
Oh yeah, that makes sense.
00:47:35.791 --> 00:47:38.293
There's a lot of demand for knowledge there.
00:47:38.293 --> 00:47:43.230
So, I know that you've got some really exciting features on Privado's roadmap.
00:47:43.230 --> 00:47:45.090
Would you mind sharing a few of those with us?
00:47:45.432 --> 00:47:45.773
For sure.
00:47:45.773 --> 00:48:00.512
I think broadly, again, as I kind of laid out, our vision is to be the platform where privacy and engineering teams can come together, collaborate, and they can confidently ship features fast with privacy built- in from the get go.
00:48:00.512 --> 00:48:03.688
And once you have this vision, saying, "Ok, this is what we want to do".
00:48:03.688 --> 00:48:12.567
We want to enable speed - for the developer, it's a good experience with less privacy risk, better privacy experience for the end user.
00:48:12.567 --> 00:48:15.811
It really forces us to solve for some things.
00:48:15.811 --> 00:48:18.532
The first problem is this visibility problem .
00:48:20.146 --> 00:48:26.592
as As a privacy professional, if you're working in a technology company, one question if you want to answer is "I have this product, product A.
00:48:26.592 --> 00:48:29.610
Show me the data flow diagram of that.
00:48:29.610 --> 00:48:39.673
I mean, it's so hard to answer that question, even with all the work that has been done; even if you bought a privacy program management tool, did the data mapping, bought a data discovery tool.
00:48:39.673 --> 00:48:44.776
Still, you're not able to answer that because the tooling was not built to answer this question.
00:48:44.776 --> 00:48:54.912
So, our motivation, our vision, all the features that are coming up is "hey, we already probably solved the problem to a good extent, but it has to be super simple.
00:48:54.912 --> 00:48:58.173
Someone can answer this question really, really fast.
00:48:58.173 --> 00:49:09.831
And then, the next level is, for example, we can automate documentation like RoPA for 40% - 50%, and then now, we've just taken it up to even 70+% thanks to our language model.
00:49:09.831 --> 00:49:19.132
So, how can you use code - the source of truth - to build this documentation, which are evergreen, which are coming from the code, which have a lot of context as well?
00:49:19.132 --> 00:49:21.893
So, that's kind of the first big puzzle that we are solving.
00:49:22.545 --> 00:49:27.635
The second big puzzle we are trying to solve for is making privacy- by- design programmatic.
00:49:27.635 --> 00:49:30.411
A lot of efforts are done in.
00:49:30.411 --> 00:49:31.354
.
00:49:31.354 --> 00:49:38.974
.the entire privacy- by- design process is to do privacy reviews, which are super important to do at the design stage for large features.
00:49:38.974 --> 00:49:43.472
But, you can also go into a rabbit hole where you can continue to do them.
00:49:43.472 --> 00:49:48.333
You can really scale them up, which is where you do so many privacy reviews that you have zero rest.
00:49:48.333 --> 00:49:50.409
And then what?
00:49:50.409 --> 00:49:52.394
That reduces the development speed.
00:49:52.394 --> 00:49:59.394
That literally halts product innovation; and, in today's environment, if you are not innovating, your company is kind of suffering.
00:49:59.644 --> 00:50:10.572
So, how can you make it to a point where you're reviewing the right stuff and then a code scanning solution is taking care of everything else, and a part of it is the product?
00:50:10.572 --> 00:50:15.057
A larger part of it is also open sourcing these privacy rules that we have.
00:50:15.057 --> 00:50:17.894
So, a large part of work is happening there as well.
00:50:17.894 --> 00:50:19.411
I'm super excited about that.
00:50:20.025 --> 00:50:29.251
Then, I would say the third thing is going deeper into this full collaboration space of privacy and engineers and these technical reviews; and again, helping them scale up.
00:50:29.251 --> 00:50:50.934
So, we have an interesting product there as well, wherein we are kind of looking at stuff like PRDs, ERDs and trying to help people streamline or triage and say, "Hey, these are the five requests that you should definitely review and these are the ones that you can kind of safely ignore and let the privacy code scanner take care of it.
00:50:50.934 --> 00:51:01.630
" But again, overall vision is to have this one platform where these two personas can work together; and, for that, we have to solve for visibility, governance, and collaboration.
00:51:02.512 --> 00:51:02.793
Awesome.
00:51:02.793 --> 00:51:03.769
Thank you so much for that.
00:51:03.769 --> 00:51:11.713
Privacy engineering is a small but growing field, for sure; and you definitely have a front row seat to its development.
00:51:11.713 --> 00:51:15.751
You're working with customers from a variety of industries and of different sizes.
00:51:15.751 --> 00:51:21.590
Can you tell us what trends you're seeing in this space and how do you see the field shaping up over the next two years or so?
00:51:22.050 --> 00:51:26.070
Yeah, sure, I think the basic trend I'm seeing is it's becoming very popular.
00:51:26.070 --> 00:51:30.570
Companies have decided, and they're hiring privacy engineers.
00:51:30.570 --> 00:51:38.052
We run a Privacy Community where we post on our Job Board new jobs, and there are always new jobs almost every week.
00:51:38.052 --> 00:51:40.432
It is getting popular.
00:51:40.432 --> 00:51:43.052
So, that's a net positive trend, I would say.
00:51:43.724 --> 00:52:10.374
The second thing is, at least what I've seen, is Privacy Engineers are getting successful at their jobs, which means they are becoming successful in a company to actually take the amazing work of the privacy professionals - the Chief Privacy Officer, the Chief Legal Officer - have done on the policy side (on creating internal policies, best practices, record keeping) and translate them into engineering requirements and tools that they can use to scan, build, buy - all of that work.
00:52:10.374 --> 00:52:30.931
One of the simplest trends I'm seeing is existing Privacy Engineers are getting successful in reducing privacy risk; successful in building privacy features and tooling; and, hence, it's a nice cycle wherein because they're getting successful, they're going to newer companies and newer companies are hiring more Privacy Engineers and that's an amazing cycle.
00:52:30.931 --> 00:52:34.673
This one thing I'm seeing is there are more Privacy Engineers that are coming in.
00:52:34.673 --> 00:52:44.692
It's still a small community of people where everyone is super helpful, sharing information, and trying to network with each other to share best practices.
00:52:44.692 --> 00:52:45.956
It is growing.
00:52:45.956 --> 00:52:50.396
I think that's one trend that I'm seeing in the space.
00:52:50.664 --> 00:52:50.664
Awesome.
00:52:50.664 --> 00:52:52.893
How do you think it's going to shape up over the next two years or so?
00:52:53.125 --> 00:52:55.594
Again, I think it's just kind of mainstreaming.
00:52:55.594 --> 00:53:02.331
Mainstreaming would mean that we would have better KPIs for different things.
00:53:02.331 --> 00:53:06.849
I do think, for example, Nishant's book talks about KPIs for data discovery.
00:53:06.849 --> 00:53:13.068
I do think there will be KPIs for Technical Privacy Reviews or Privacy Engineering Assessments, which will become popular.
00:53:13.068 --> 00:53:31.349
I do think privacy code scanning will become mainstream, and that's what we've seen with our customers - the Privacy Engineers taking the lead because they would be the ones who will be like "Hey, we have this nice automated check as part of SDLC, which is looking for things, so we are doing high- level work, more important work in the company as well.
00:53:31.885 --> 00:53:45.764
I'm not sure about this, but I think the impact of AI governance, Privacy Engineers might also play a big role there, but that's so early that I don't really know for sure.
00:53:45.764 --> 00:53:51.405
Definitely, they'll have a big role to play, but I don't know how much they will end up owning that piece.
00:53:51.405 --> 00:53:51.405
.
00:53:51.405 --> 00:53:51.405
.
00:53:51.405 --> 00:53:55.974
I mean, it'll be a shared responsibility, but I don't know the exact answer to that.
00:53:55.974 --> 00:54:00.168
But at least, these are a couple of trends, or couple of ways, I can see the field shaping up.
00:54:01.132 --> 00:54:01.775
Thank you so much.
00:54:01.775 --> 00:54:06.777
Do you have any words of wisdom to leave the audience with before we close?
00:54:07.085 --> 00:54:14.336
No, I mean, I just wanted to come here on the podcast and share our journey and what we've been doing with Privado.
00:54:14.336 --> 00:54:19.311
Again, personally, we as a company are super grateful to the privacy community.
00:54:19.311 --> 00:54:25.713
I think privacy in general, I think are the most open people, most accepting people, most diverse people.
00:54:25.713 --> 00:54:33.134
Everyone is trying to solve the user's problem, which sounds super exciting because you're looking things from the user's angle.
00:54:33.134 --> 00:54:36.610
Obviously, you have the business metrics, but you're looking at things from the business angle.
00:54:36.610 --> 00:54:46.510
So, yeah, we're super appreciative and thankful to the entire privacy community for accepting us, and working with us, and giving us good and nice feedback and critical feedback as well.
00:54:46.510 --> 00:54:52.231
And, we really look forward to working with everyone who's listening on the podcast in the future as well.
00:54:53.125 --> 00:54:54.612
Yes, everyone, go check out Privado.
00:54:54.612 --> 00:54:57.795
I'll put the link in the show notes.
00:54:57.795 --> 00:55:07.554
Well, Vee, thank you so much for joining us today on The Shifting Privacy Left Podcast to talk about privacy code scanning, Privado, and the rise of privacy engineering.
00:55:07.554 --> 00:55:08.949
[Vaibhav: Thanks, Debra, for having me here.
00:55:08.949 --> 00:55:15.733
] Until next Tuesday, everyone, when we'll be back with engaging content and another great guest, or guests.
00:55:15.733 --> 00:55:21.153
Thanks for joining us this week on Shifting Privacy Left.
00:55:21.153 --> 00:55:23.490
Make sure to visit our website, shiftingprivacyleft.
00:55:23.490 --> 00:55:28.688
com, where you can subscribe to updates so you'll never miss a show.
00:55:28.688 --> 00:55:33.690
While you're at it, if you found this episode valuable, go ahead and share it with a friend.
00:55:33.690 --> 00:55:42.269
And, if you're an engineer who cares passionately about privacy, check out Privado: the developer-friendly privacy platform and sponsor of the show.
00:55:42.269 --> 00:55:43.989
To learn more, go to Privado.
00:55:43.989 --> 00:55:44.510
ai.
00:55:44.510 --> 00:55:48.614
Be sure to tune in next Tuesday for a new episode.
00:55:48.614 --> 00:55:49.385
Bye for now.
00:00:49.762 --> 00:00:55.273
Our goal is that if we do all of this work well, you start with the place where you already have the data map.
00:00:55.273 --> 00:01:07.479
Once you have the data map, you actually can see the risk really quickly and you can then you can do the good work; you can go take that risk to the Engineering Lead or the Developer and say, "Hey, there is a risk and we want to reduce it.
00:01:07.479 --> 00:01:11.271
There are four ways how we can do it, and let's work on that.
00:01:11.271 --> 00:01:19.325
" So you save all of the work, all of the time you're spending in manually building these data and you get all of that time free.
00:01:19.325 --> 00:01:25.439
And, you spend all of that time in actually reducing the risk and actually putting a privacy ticket on the Jira board, which gets shipped.
00:01:25.439 --> 00:01:27.507
So, the risk is less.
00:01:27.507 --> 00:01:28.691
Your users actually see it.
00:01:34.539 --> 00:01:36.844
Hello, I am Debra J Farber.
00:01:36.844 --> 00:01:48.930
Welcome to The Shifting Privacy Left Podcast, where we talk about embedding privacy by design and default into the engineering function to prevent privacy harms to humans, and to prevent dystopia.
00:01:48.930 --> 00:02:00.933
Each week, we'll bring you unique discussions with global privacy technologists and innovators working at the bleeding edge of privacy research and emerging technologies, standards, business models, and ecosystems.
00:02:00.933 --> 00:02:04.944
Welcome everyone to Shifting Privacy Left.
00:02:04.944 --> 00:02:08.832
I'm your Host and resident privacy guru, Debra J Farber.
00:02:08.832 --> 00:02:23.698
Today, I'm delighted to welcome my next guest, Vaibhav Antil (also known as Vee), the CEO and Co-Founder of Privado, the privacy tech platform that's bridging the privacy engineering gap, and sponsor of this podcast.
00:02:23.698 --> 00:02:25.685
Welcome, Vee!
00:02:25.784 --> 00:02:25.784
Hi Debra.
00:02:25.784 --> 00:02:26.287
Hi everyone.
00:02:27.100 --> 00:02:30.204
Before we start, I want to say a few things to you, Vee.
00:02:30.204 --> 00:02:46.149
I've had the privilege of serving as a member of Privado's Advisory Board, along with Nishant Bajaria, for the past two and a half years, advising on go-to-market messaging, thought leadership and Shifting Left evangelism; and it's been such a wonderful ride.
00:02:46.149 --> 00:02:59.459
I even remember when I was on vacation in Belgium a little over a year ago and received an email from you, Vee, asking me whether I'd consider launching a podcast that's focused on privacy engineering because Privado wants to sponsor it.
00:02:59.459 --> 00:03:01.407
I could not have been more excited.
00:03:01.407 --> 00:03:22.296
That really kicked off and started my creative journey with the Shifting Privacy Left podcast, and it's enabled me to bring this content for a growing niche audience, and I just want to take this time to publicly thank you for believing in me early on and supporting this really important educational initiative.
00:03:23.180 --> 00:03:31.590
I'm glad we could work this out and be sponsoring the podcast, and it's been amazing in creating such great content.
00:03:31.590 --> 00:03:38.439
I especially love a couple of episodes, and with so much diverse opinions and experiences.
00:03:38.439 --> 00:03:45.612
So, I learned a lot from this podcast and we've been, you know, super excited sponsoring it and continue to do so as well.
00:03:46.539 --> 00:03:47.320
Thank you so much.
00:03:47.320 --> 00:03:59.982
It really means the world to me, and I can coo and talk about how much I love Privado and you and the entire team, but I think people probably want to hear about the topic of the day; and that's several things.
00:03:59.982 --> 00:04:10.075
We're going to be talking about privacy code scanning; what 'shifting privacy left' means, especially into DevP rivO ps; and then, the importance of bridging the privacy engineering gap.
00:04:10.075 --> 00:04:21.396
So, we'll just kick things off by me asking you a little bit about Privado and how you decided to focus on code scanning for privacy and solving privacy engineering challenges.
00:04:22.841 --> 00:04:30.247
For the audience who might not be aware of Privado, Privado is a platform where privacy and engineering teams collaborate.
00:04:30.247 --> 00:04:35.953
They come together to ensure the products the companies are shipping are built with privacy from the get go.
00:04:35.953 --> 00:04:47.786
I would imagine the same role in a company is played by a privacy engineer or another privacy professional who's acting like this connective tissue or who's bridging this gap between privacy and engineering teams.
00:04:47.786 --> 00:04:58.480
I would like to think Privado is the co- pilot for this person, this Privacy Engineer or this privacy professional who's working with engineering teams, whose core job is to work with engineering teams.
00:04:59.381 --> 00:05:03.406
Essentially, my journey into privacy has been different.
00:05:03.406 --> 00:05:08.893
I mean, at least this is probably the most interesting question I ask everyone: how did you end up in privacy?
00:05:08.893 --> 00:05:11.196
And, everyone has different answers and different paths.
00:05:11.196 --> 00:05:14.983
So, my path came in from a product management role.
00:05:15.504 --> 00:05:28.396
I was a product manager for an online music streaming company, and I had seen the world where business goals as a product manage are: revenue, active users, engagement were super critical.
00:05:29.401 --> 00:05:41.874
I had this deep empathy for engineers - developers who are building these products - because they were kind of the centerpiece of shipping these features fast, which could, move the revenue numbers, the engagement numbers.
00:05:41.874 --> 00:05:44.217
They could literally do magic by building these features.
00:05:44.780 --> 00:05:53.812
While I had this experience, I ended up getting involved into a privacy project with the legal team there and kind of saw the other world - which was a privacy world.
00:05:54.172 --> 00:06:03.362
I felt that was pretty exciting, as well, because they were trying to protect the user data, do right with the user, which as a product manager, whatever you're building, you want to do.
00:06:03.362 --> 00:06:10.531
You want to make sure the promises that you are making kind of consistent and the end users' privacy is protected.
00:06:10.531 --> 00:06:13.775
That's kind of how I got introduced to privacy.
00:06:15.196 --> 00:06:15.196
When I started Privado.
00:06:15.196 --> 00:06:15.477
.
00:06:15.477 --> 00:06:15.497
.
00:06:15.497 --> 00:06:17.819
actually, the first thing I did was I tried to be like a privacy professional.
00:06:17.819 --> 00:06:26.310
I said "he first thing I'm going to do is do a data mapping project for an e-commerce company and I still remember that was.
00:06:26.310 --> 00:06:31.817
That was a sizable company, was a large e-commerce company and I probably interviewed about 80 people.
00:06:31.817 --> 00:06:49.996
That was a mix of Product Managers, Engineers, Engineering Leaders, Data Managers, Data Engineers, and the project was this crazy project to map in an Excel sheet the microservices, the data pipelines, all the products they have, and how data comes into the company and where all it goes.
00:06:49.996 --> 00:07:02.196
I still remember, I did this huge exercise - probably took like two and a half, three months - and I went to my CTO and said, "Hey, look at this sheet and this is basically around which we have to build the product.
00:07:02.956 --> 00:07:11.766
At that point of time, I was still thinking more assessments; that was kind of the way privacy teams used to get this data, which I got via interviews.
00:07:11.766 --> 00:07:27.605
But, when my CTO looked at it, he kind of had a different idea; and he basically said to me that there were probably like 30%- 40% of this information we can get by scanning the code and the rest - something we might still have to do manually - at least it'll take you that far.
00:07:28.567 --> 00:07:37.417
That led me to a realization; that was kind of our spark or our Eureka! moment where we're like, "Hey, nobody is kind of doing this at the moment.
00:07:37.860 --> 00:07:45.146
If we attack the problem from code scanning, it's a very good experience for the privacy team because they get to this information super fast.
00:07:45.146 --> 00:07:54.877
For the engineer, it's a really superior experience because when you're talking to them, the biggest problem was not understanding what a lawyer is saying.
00:07:54.877 --> 00:07:57.322
So, they get to see the same things.
00:07:57.322 --> 00:08:00.384
They get to see data in a format they understand.
00:08:00.384 --> 00:08:03.389
" And, we were early to market.
00:08:03.389 --> 00:08:04.910
So, that was exciting to me as well.
00:08:05.230 --> 00:08:15.503
So that's how privacy code scanning got started, with this huge Excel RoPA data mapping exercise; and now, of course, the vision has evolved.
00:08:17.283 --> 00:08:38.946
It started with doing RoPA, then data mapping (very, very small), and as we got some customers and started working with them, now of course, our vision is to actually be the single platform where privacy teams and engineering teams will collaborate and building a platform that engineers love and not hate, which actually gets adopted, and the privacy risk goes down.
00:08:38.946 --> 00:08:46.191
You could get more privacy issues, reviews; you can get some privacy functionalities as part of a Jira board.
00:08:46.191 --> 00:08:53.896
So, kind of enabling the privacy function, and at the same time making sure developers actually like the experience and they're engaged, as well.
00:08:53.896 --> 00:08:58.569
So, that's a little bit about how we started with code scanning and where we are in our journey.
00:08:59.480 --> 00:09:00.160
Thank you for that.
00:09:00.160 --> 00:09:01.263
That's really helpful.
00:09:02.124 --> 00:09:08.573
I know that the mantra for Privado is 'bridging the privacy engineering gap.
00:09:08.573 --> 00:09:11.497
' Can you talk a little bit more about this gap?
00:09:11.497 --> 00:09:12.480
What do you mean by it?
00:09:12.799 --> 00:09:22.349
I think this is something at least as we started, or as the initial concept of doing a code scan happened, we started speaking to privacy professionals in Europe and the U.
00:09:22.349 --> 00:09:22.668
S.
00:09:22.908 --> 00:09:31.257
I remember that we used to have slides saying where we were trying to put on some challenges that they face, and one of the things we had was 'Is engineering a black box?
00:09:31.257 --> 00:09:34.644
' Engineering is not a black box.
00:09:34.644 --> 00:09:38.069
We still know things, but there is a huge gap in our understanding.
00:09:38.069 --> 00:09:41.074
What we're trying to ask, the engineers don't understand what they tell.
00:09:41.074 --> 00:09:46.584
Sometimes we don't understand, and that's how the full concept of this privacy engineering gap came in.
00:09:46.584 --> 00:09:57.975
I also, at that point of time, read a blog post - I think it was on Adobe, where it was something like 'Privacy Principles Are from Venus; Engineering Requirements are From Mars.
00:09:57.975 --> 00:09:59.260
' S omething similar.
00:09:59.260 --> 00:10:02.764
So, a couple of things came together while we were thinking about this.
00:10:02.764 --> 00:10:07.548
But broadly, if you look at the reason on why there is a gap, I think there are three big reasons.
00:10:08.789 --> 00:10:15.096
1) I think the first big reason I've seen is there is this kind of difference in the approach of how these two functions work.
00:10:15.096 --> 00:10:19.725
So, kind of on the stakeholder level, right at the top, there's a misalignment.
00:10:19.725 --> 00:10:22.968
If you look at privacy, privacy is a very central function.
00:10:22.968 --> 00:10:23.369
Right?
00:10:23.369 --> 00:10:33.360
There's a central team who's trying to make sure use of data is consistent with the privacy promises made; or data actually gets deleted; or you're collecting less data.
00:10:33.360 --> 00:10:33.480
Right?
00:10:33.480 --> 00:10:40.789
All the nice, great privacy work, but that's done by a central team and they have the central view of things.
00:10:40.789 --> 00:10:47.360
So, look at engineering; it basically evolved from the day where it was central to super decentralized, distributed teams.
00:10:47.360 --> 00:10:47.480
Right?
00:10:47.480 --> 00:11:10.736
You have a small team of a Product Manager ,and a couple of Developers, and one Designer - sometimes just engineers who are experimenting and pushing features out, which means on one side, you want the central view of data and privacy; and on the other hand, you have this decentralization: where they are making decisions of data, architecture, tooling, decision- making on their own.
00:11:10.736 --> 00:11:15.455
So, that's the one big gap that we see is like just the way these two functions.
00:11:15.455 --> 00:11:16.177
Things are different.
00:11:16.430 --> 00:11:19.598
2) I think the second related gap here is also the speed.
00:11:19.598 --> 00:11:29.817
Engineers are kind of shipping things on a weekly, sometimes daily, basis; but, for any privacy teams, to catch up here becomes a big problem, and the tooling hasn't caught up.
00:11:29.817 --> 00:11:31.255
So, that's another conversation.
00:11:31.255 --> 00:11:36.834
So, I would say the first big problem I see is, overall, how these functions are structured are slightly different.
00:11:36.834 --> 00:11:43.176
I would imagine it's the same thing with security as well, but they have better tooling at this point to tackle all of these challenges.
00:11:43.176 --> 00:11:48.095
The second thing I see is which becomes a problem is lack of shared vocabulary.
00:11:48.095 --> 00:11:55.720
So, it's kind of like the problem is that none of these laws is descriptive; everything is written in a more principle- based way.
00:11:56.190 --> 00:12:01.038
But, when you go to the engineering team and say, "Hey, you have to delete data, it means something.
00:12:01.038 --> 00:12:03.638
Or actually, let's take a non-privacy example.
00:12:03.839 --> 00:12:08.518
As a Product Manager, I would go and say, "hey, our website has to be fast.
00:12:08.518 --> 00:12:14.575
It doesn't mean anything right now, but for an engineer it will mean something when you talk in seconds.
00:12:14.575 --> 00:12:15.514
"Okay, what does it mean?
00:12:15.514 --> 00:12:17.394
How far should the page load?
00:12:17.394 --> 00:12:18.298
What is fast?
00:12:18.298 --> 00:12:23.913
Is it 10 seconds, one second, micro second, or you can have.
00:12:23.913 --> 00:12:27.658
You can say the same thing about the specific API that, as a product manager, I own.
00:12:27.658 --> 00:12:29.377
Like you know, the response time has to be X.
00:12:29.377 --> 00:12:31.036
It has to be available for Y time.
00:12:31.036 --> 00:12:34.019
You cannot go and say our API has to be available.
00:12:34.019 --> 00:12:37.452
" there has to be some number which makes sense for the engineer.
00:12:37.990 --> 00:12:49.216
So now, once you look at this lens and go back to the privacy laws, they are not prescriptive in that sense; and hence it, becomes very difficult to operationalize privacy.
00:12:49.289 --> 00:12:52.432
3) So, you have this gap where they're not speaking the same language.
00:12:52.432 --> 00:12:57.019
The law itself is not prescriptive; and hence, it leads to the friction between the two teams.
00:12:57.019 --> 00:13:15.914
And a combination of this, I think, finally leads to a point where you might start with a very engaged privacy and engineering team; but, as engineering teams look at that, they did a bunch of assessments and questionnaire and they did not get any privacy request to implement in the product.
00:13:15.914 --> 00:13:20.296
It leads to a point where it looks, to Engineering Teams, that privacy has become a blocker.
00:13:20.296 --> 00:13:29.538
And, engineers are smart, so they try to then find ways around your DPI or PI process, which means you have now even more risk.
00:13:29.538 --> 00:13:37.336
So, I feel like these are three kind of structural things because of which there is this gap between privacy and engineering teams.
00:13:37.336 --> 00:13:45.778
100% solvable; that's what I think any privacy person working closely with engineers, or a typical privacy engineer ,is trying to do as well.
00:13:45.778 --> 00:13:48.937
That's what we, as Privado, are trying to solve, as well.
00:13:49.810 --> 00:13:50.975
That makes a lot of sense to me.
00:13:50.975 --> 00:14:07.096
One other area that I think is just very, very different between engineers and the privacy function that comes out of Legal / GRC traditionally is that lawyers don't want risk documented where there are unknowns and you don't know how to solve it.
00:14:07.096 --> 00:14:10.219
There was a time, for instance, that I was working on a major.
00:14:10.219 --> 00:14:10.990
.
00:14:10.990 --> 00:14:11.050
.
00:14:11.050 --> 00:14:22.956
a major breach had happened at a company, at a retail company; and I was one of the subcontractors working on that, and we needed to document the 'as- is' state for privacy and then come up with the 'to- be' state for privacy.
00:14:22.956 --> 00:14:32.816
So, that involved lots and lots of interviews with various types of people, including engineers and the attorneys on that case didn't want anything that was put in discovery.
00:14:32.816 --> 00:14:33.050
.
00:14:33.050 --> 00:14:33.070
.
00:14:33.070 --> 00:14:42.159
they didn't want anything that could be like "You did things wrong and now it's at trial and could be part of the discovery process, so they did not want us to document any of the risk.
00:14:42.159 --> 00:14:49.137
So, as a result, they put all of these attorneys in our meetings to make sure that those meetings were covered by privilege, right?
00:14:49.289 --> 00:14:54.278
I mean, how different is that from engineering, where it's like let's get to the meat of this problem.
00:14:54.278 --> 00:14:55.140
Let's root cause it.
00:14:55.140 --> 00:14:58.234
Let's document and make sure that we address it and fix it.
00:14:58.234 --> 00:14:58.769
Right?
00:14:58.769 --> 00:15:20.595
Right"And so those two different perspectives have been a real friction point and I think I definitely think something like Privado makes it so that the Legal and the GRC folks can have insights derived from all the great work that code scanning does and the data mapping and stuff that you do; but also give the engineers the granular data points, so that they can take action to address privacy risk.
00:15:20.595 --> 00:15:25.634
I just wanted to tell that little story because I definitely think that that's a wide gap between Engineering and Legal.
00:15:26.509 --> 00:15:31.695
However, what I've been seeing in the industry for the last couple of years is.
00:15:31.695 --> 00:15:31.695
.
00:15:31.695 --> 00:15:31.695
.
00:15:31.695 --> 00:15:45.700
one of the good things that all these regulations have done and also, I think, in general user behavior change and how much they care about privacy - is that companies have realized that this work is not going anywhere.
00:15:45.700 --> 00:15:55.980
So, while maybe the earlier approach might be to document less, I think companies slowly are realizing that they have to do the work.
00:15:55.980 --> 00:16:11.774
Once you have to do the work, everyone is, I think, reaching the same conclusion actually, is that we will need to finally take these legal policies and translate something actionable for the engineers where things happen right.
00:16:12.450 --> 00:16:17.038
That's the reason why more and more companies have now a Privacy Center and more is being launched.
00:16:17.038 --> 00:16:19.231
So, they have an open privacy center.
00:16:19.231 --> 00:16:24.076
A very simple example is to say "Hey, send an email to this person for your DSR to kickstart.
00:16:24.076 --> 00:16:35.138
So I think, as companies have realized that there's no chance that DSR is going down or there's no way that they can go away with features that have less privacy, they're now making it more formal.
00:16:35.138 --> 00:16:40.298
A consequence of that is you will see more Privacy Engineers being hired in new companies.
00:16:40.298 --> 00:16:44.055
Companies with existing Privacy Engineers are starting up more, as well.
00:16:44.055 --> 00:16:55.534
So, I do think that's a big trend shift which has happened in industries that companies have come to that conclusion, and they are now staffing up, building processes, and buying tooling for the exact same reasons.
00:16:56.518 --> 00:16:56.819
Awesome.
00:16:56.819 --> 00:17:02.774
So, how can engineers provide visibility into the personal data that applications are collecting and using?
00:17:03.110 --> 00:17:07.441
Unfortunately, this is kind of a very tough problem.
00:17:07.441 --> 00:17:09.474
Again, let me take a step back.
00:17:09.474 --> 00:17:27.681
If you talk in generalities - nothing related to personal data - I think one thing that people have been trying to do, or were trying to create another kind of documentation, is network diagram, architecture diagrams; which a lot of engineers create as part of their requirement.
00:17:27.681 --> 00:17:32.557
Maybe it's part of their company's policy or they have to do it because it's a sales facing document.
00:17:32.557 --> 00:17:43.355
It's very difficult to even get that updated, which has very high motivation for the engineering teams to maintain or accurate version of it, right, they'll see like all those documentation get outdated as well.
00:17:43.355 --> 00:17:45.517
The same is true for their service names.
00:17:45.517 --> 00:17:45.738
Right?
00:17:45.950 --> 00:18:06.276
Nobody has a clear idea of "Okay, I have built this product, which is basically this backend microservice," and then over time, a lot of other components in engineering starts to interact, like your website dashboard and some other backend systems, and then someone makes a change in this specific component and 10 things break on each side.
00:18:06.276 --> 00:18:14.838
Essentially, I mean, if I take a step back and look at it, documentation of any kind is tough when things are decentralized and are changing fast.
00:18:15.230 --> 00:18:25.891
That's where the engineers operate, so they have a product or an application which was built by let's say, if you start to do it today, built by some engineers who are not in the company.
00:18:25.891 --> 00:18:33.919
It probably has hundreds of thousands to millions of lines of code, which means there's no single person who can actually tell you what is in there.
00:18:33.919 --> 00:18:37.039
What they can do, is they can at least give you a good starting point.
00:18:37.039 --> 00:18:38.957
I think engineers can give you a good starting point.
00:18:38.957 --> 00:18:47.217
The biggest gap I see there is what a privacy person means 'personal data' is; the definition is not the same for engineers.
00:18:47.217 --> 00:18:56.396
They might be thinking PII, like email address; and as you start to have those conversations, they will give you more information like "oh yeah, we do have clickstream data that we collect.
00:18:56.396 --> 00:18:58.277
Oh yeah, we do collect audit data.
00:18:58.277 --> 00:18:59.315
Is that even personal data?
00:18:59.315 --> 00:19:01.959
So I think it is super challenging.
00:19:01.959 --> 00:19:08.579
But current engineers can give you at least a starting point on what data are they collecting and using.
00:19:08.579 --> 00:19:15.976
Directionally, you will get the right answer, but an accurate representation, depending on what stage you are.
00:19:15.976 --> 00:19:15.976
.
00:19:15.976 --> 00:19:15.976
.
00:19:15.976 --> 00:19:24.336
if you are at a decent stage; which means your company has been there for a while; which means there are multiple people who built the product; and which means it'll be super complex.
00:19:25.329 --> 00:19:27.778
At this stage, I would recommend to do more automation.
00:19:27.778 --> 00:19:29.676
One type of automation is doing code scanning.
00:19:29.676 --> 00:19:38.451
Another automation, or actually, even if you don't want to automate, you can just look at your product, go to the website, try to use it and say, "Oh, I see one data element which is missing, I see another.
00:19:38.451 --> 00:19:42.038
" Do it in a session, and you will actually uncover even more data elements.
00:19:42.038 --> 00:19:56.278
So, a session where you can go through the product and then ask questions will give you more data elements than just sending an Excel sheet or assessment; and ideally, what you want to do is generate these documentations from automated tools.
00:19:56.278 --> 00:20:07.216
I believe privacy code scanning - of course I'm biased - is one of the better ways to do that because it's generating the document from the source of truth, which is the code; and it actually enables engineers.
00:20:09.732 --> 00:20:14.598
In fact, to that point, the Google Play Store came up with this requirement to generate Play Store Data Safety Report.
00:20:14.598 --> 00:20:23.051
We actually open sourced, and made available, a free tool - it is still available - called Play Store Data Safety Generator; and what it does.
00:20:23.051 --> 00:20:23.373
.
00:20:23.373 --> 00:20:35.259
.(and it got downloaded, I think, thousands of times) where Android engineers came in, downloaded the app, ran a scan on their Android application, and it prefilled nearly 80% of the Play Store Data Safety Report.
00:20:36.091 --> 00:20:39.353
At the end of the day, they filled out the rest of the stuff, downloaded it, and put it there.
00:20:39.353 --> 00:20:47.317
So, that's another example of a code scanning approach, where you're using some automation to generate these documents actually help.
00:20:47.317 --> 00:20:51.538
So, again - it's a long answer, but to summarize, use automated tools.
00:20:51.538 --> 00:20:52.976
Your engineers will thank you for that.
00:20:52.976 --> 00:20:54.855
If not, do a session with them.
00:20:54.855 --> 00:20:55.719
That works as well.
00:20:55.719 --> 00:20:58.337
I did that when I was trying to do it the first time.
00:20:59.652 --> 00:21:03.478
That's definitely is easier to do when you just have maybe one product or team.
00:21:03.478 --> 00:21:09.235
But, if you're like a privacy person that comes in as a consultant, that's like "oOkay, we've never done this before.
00:21:09.235 --> 00:21:12.098
Go and get data maps of all our products.
00:21:12.098 --> 00:21:17.798
Have all of these interviews"- I mean something I've done before; it is a massive, massive effort.
00:21:17.798 --> 00:21:20.878
So, I definitely think automation comes in handily that way.
00:21:21.711 --> 00:21:27.514
Just to add one thing - one of our core motivations is, at the end of the day, as privacy professionals,
00:21:27.976 --> 00:21:37.576
as privacy engineers, you really want to go in and build something in the product or remove certain flows which should not be there in the product.
00:21:37.630 --> 00:21:48.856
So, you want to reduce privacy risk, and you want to shift privacy features; but, the majority of the work is spent in collecting data, is asking people questions, is building this data map, which I feel should not be there.
00:21:49.210 --> 00:22:07.713
Our goal is that, if we do all of this work well, you start with the place where you already have the data map; and once you have the data map, you actually can see the risk really quickly and you can then do the good work, which is, you can go take that risk to the Engineering Lead or the Developer and say, "hHey, there is a risk and we want to reduce it.
00:22:07.713 --> 00:22:19.434
There are four things how we can do it and let's work on that; but you save all of the work, all of the time you are spending in manually building these data maps, and you get all of that time free.
00:22:19.434 --> 00:22:26.115
You spend all of that time in actually reducing the risk and actually putting a privacy ticket on the JIRA board, which gets shipped.
00:22:26.115 --> 00:22:27.675
So, you know the risk is less.
00:22:27.675 --> 00:22:28.855
Your users actually see it.
00:22:28.855 --> 00:22:40.682
" I would say that's the strongest argument I have personally seen for automation is you you free up time which can be used to do better things, for things which can impact the user privacy immediately.
00:22:42.207 --> 00:22:43.651
Exactly, I totally agree.
00:22:43.651 --> 00:22:51.217
In fact, I was going to ask you, why is shifting privacy left into DevOps important to you, but I think you kind of summed up some of the reasons why.
00:22:51.217 --> 00:22:53.951
I want to give you the opportunity to add anything.
00:22:53.951 --> 00:22:53.951
.
00:22:53.951 --> 00:22:53.951
.
00:22:55.745 --> 00:22:58.803
to answer the question holistically: why is shifting left important?
00:22:58.803 --> 00:23:02.913
You could shift left into design, shift left into architecture.
00:23:02.913 --> 00:23:07.813
Privado focuses on DevOps, so I wanted to highlight that and get an understanding from you.
00:23:07.985 --> 00:23:08.267
Yeah, sure.
00:23:08.267 --> 00:23:15.480
I think one of the great things that has happened in engineering is people have moved to this agile development.
00:23:15.480 --> 00:23:22.386
A part of it is also continuous software delivery, which means you are continuously shipping features out.
00:23:22.386 --> 00:23:23.990
You're fixing bugs super fast.
00:23:23.990 --> 00:23:33.114
For the end user, it's amazing because, let's say, our own customer, we find a bug today; we can literally fix the bug and, in the next 10 minutes, it gets deployed.
00:23:33.114 --> 00:23:42.871
So, companies have built this amazing tooling and infrastructure for engineers where they can build features, release them, and they go live at the customer level super fast.
00:23:43.030 --> 00:23:46.567
Because of cloud and best DevOps practices, it's possible.
00:23:46.827 --> 00:23:49.135
So, a lot of investment has gone into this.
00:23:49.135 --> 00:23:56.441
How can we actually build fast, ship fast so our end users can get to see these features fast?
00:23:56.441 --> 00:24:06.076
Once you wear this hat and say, "okay, my company is going to change things super fast, right, they're going to change things every week, things are going to get shipped every second.
00:24:06.076 --> 00:24:20.586
" Then, you can't have a privacy mindset, which is thinking weeks or months, which is typically like a privacy impact assessment or a data protection impact assessment At the design stage you do want to spend time because the feature has not started to be developed.
00:24:20.586 --> 00:24:24.015
So, you can spend that time and do technical privacy reviews, etc.
00:24:24.015 --> 00:24:29.749
But, once all of that is done, there is huge work which doesn't come into that regular design cycle.
00:24:29.749 --> 00:24:42.267
It goes through this continuous software delivery model where in engineers are writing code, they're pushing code, things don't remain the same from a design to an implementation phase, and that's basically a missing gap in the current privacy programs.
00:24:42.267 --> 00:24:49.048
You don't really have an oversight there, and that's what shifting privacy into the DevOps process means.
00:24:49.048 --> 00:25:08.426
It means, as a privacy professional, you have a privacy check as part of this DevOps cycle, which ensures the new code changes which are happening, the configuration changes which are happening, a new database being created, a new third- party being added, a new pixel being added to your website, is going through this privacy check.
00:25:08.426 --> 00:25:14.871
And then, this privacy check is looking at it and saying, "okay, this is a high risk privacy issue, we have to block it.
00:25:14.871 --> 00:25:17.116
It needs to be fixed before it goes live.
00:25:17.116 --> 00:25:22.287
Or it's a low risk, we can let it go live, but it creates a ticket for the engineer to fix later.
00:25:22.647 --> 00:25:32.050
Shifting privacy left, or this full DevPrivOps is kind of a methodology where privacy is going and saying, "hey, we have this, we shifted extremely left to the design phase.
00:25:32.050 --> 00:25:34.277
We're right at the inception of a new feature.
00:25:34.277 --> 00:25:42.678
We are doing privacy reviews and thinking about new products from a privacy perspective, both on the legal side on and on the technical privacy side.
00:25:42.678 --> 00:25:46.694
So they're going from that to saying, okay, but we also need to solve things at scale.
00:25:46.694 --> 00:25:58.913
We also need to acknowledge the fact that our engineering workflows are at a daily, weekly speed and we need to have something on the privacy side which matches that as well.
00:25:58.913 --> 00:25:58.913
"
00:25:59.433 --> 00:26:19.114
Another way that I can articulate it how a Privacy Engineering Leader told me - the way they like to think about this DevPrivOps or shifting left is a lightweight, consistent governance; wherein, instead of looking at 90 things, you look at 6 things and the rest of the 84 things are automatically checked.
00:26:19.114 --> 00:26:24.094
So, it's lightweight; it's not adding a lot of time or a lot of commitment for the developers.
00:26:24.094 --> 00:26:24.916
It's consistent.
00:26:24.916 --> 00:26:33.257
So, it checks all the time and so you are assured of whatever is going out to production, to your end user, as less privacy risk.
00:26:33.257 --> 00:26:36.387
That's the philosophy of DevPrivOps or DevOps.
00:26:36.387 --> 00:26:45.796
Yeah, shifting left just means go earlier, find things earlier so there are fewer things that you're finding in your products, which have gone live.
00:26:45.997 --> 00:26:46.277
Ideally.
00:26:46.277 --> 00:26:46.706
.
00:26:46.706 --> 00:26:46.726
.
00:26:46.866 --> 00:26:54.678
the most common one I've seen with our customers, which I never thought would be, is they find these cookies on their website.
00:26:54.678 --> 00:27:50.217
You would imagine that it would be solved, but if they have a large front end team, they'll find cookies on their website that are first- party cookies, and they're not easy to find who actually added that.
00:27:50.217 --> 00:27:50.706
Right?
00:27:50.706 --> 00:27:56.571
Because there could be 20- 30 front end engineers working on the same website or same dashboard.
00:27:56.571 --> 00:27:58.821
So, third- party cookies are easy to track.
00:27:58.821 --> 00:28:03.936
It's generally the marketing team or analytics team, but first- party cookies could be some part of the engineering team.
00:28:03.936 --> 00:28:17.696
So, that could mean the moment an engineer decides to add a cookie, it creates an issue and alert for the engineer to say "you have to onboard it to our CMP" - whatever consent management platform you use - and then, it gets shipped.
00:28:17.696 --> 00:28:24.076
So, you're not chasing the entire 40 member team when you discover it later in your cookie scan, when it hits actually production.
00:28:24.278 --> 00:28:27.500
That's shifting left in the entire DevOps world.
00:28:28.786 --> 00:28:29.127
Awesome.
00:28:29.127 --> 00:28:32.073
Before code is ever shipped to production.
00:28:32.073 --> 00:28:35.750
So, 'fix it before it's in production' is a great mantra, in my opinion.
00:28:35.750 --> 00:28:42.132
Let's talk a little bit about privacy code scanning, since that's the crux of what Privado provides.
00:28:42.132 --> 00:28:49.342
Let's start with what is a privacy code scanner and how does it differ from traditional static code analysis tools in security?
00:28:49.342 --> 00:28:56.932
And maybe, it's also a good time to bring up the difference between static code analysis and dynamic code analysis to differentiate from what you don't do.
00:28:57.786 --> 00:28:58.147
Yeah, sure.
00:28:58.147 --> 00:29:01.013
Think of a privacy code scanning as.
00:29:01.013 --> 00:29:01.914
.
00:29:01.914 --> 00:29:06.692
.the technology itself of scanning the code to look at patterns is super old.
00:29:06.752 --> 00:29:26.215
I t started with saying, "okay, our developer is writing code in a way which is consistent with our coding practices" to then, you know, looking for license compliance issues in open source packages, to the security scanning tools that you set, which is looking at, "Hey, do we have code written that a hacker can attack?
00:29:26.215 --> 00:29:27.240
You know, like, can they?
00:29:27.240 --> 00:29:31.999
Can they use this weakness in our application code to attack and get some data out?
00:29:31.999 --> 00:29:34.046
And so the concept is the same.
00:29:34.046 --> 00:29:34.668
Where you are.
00:29:34.668 --> 00:29:34.708
.
00:29:34.708 --> 00:29:39.749
.I mean, the technology is looking at the code, scanning it and then giving you out some information.
00:29:39.749 --> 00:29:44.990
In that way, the approach - that technology - is old; we just applied it for privacy.
00:29:47.925 --> 00:29:48.005
What it really means is.
00:29:48.005 --> 00:29:48.407
.
00:29:48.407 --> 00:29:48.606
.
00:29:48.606 --> 00:29:55.211
essentially, a privacy code scanner is going to scan your code of anything your engineer has built and build a data flow graph out of it.
00:29:55.211 --> 00:29:57.522
It has to basically give you a couple of data points.
00:29:57.522 --> 00:30:00.515
It has to tell you what data is coming into this application.
00:30:00.515 --> 00:30:02.081
What's coming in?
00:30:02.081 --> 00:30:04.068
What happens with that once it comes in?
00:30:04.068 --> 00:30:04.952
Where it flows?
00:30:04.952 --> 00:30:16.523
Where is it going out - which means it could go out to a database, it could go out to a cookie, it could go out to a third party, it could go to your own internal infrastructure, your own internal backend service wherever it is going.
00:30:16.523 --> 00:30:16.523
.
00:30:17.887 --> 00:30:35.026
The crux of a privacy code scanner is to build a data flow graph, or a data flow diagram, of your specific application that you're scanning and with the focus on all life cycle: collection, storage, sharing, logging, transformation, processing, all of it.
00:30:35.026 --> 00:30:41.666
Once you have this basic graph done, then on top of it, you can do a couple of interesting things.
00:30:41.666 --> 00:30:45.077
Once you have that, you can generate a RoPA report.
00:30:45.077 --> 00:30:48.970
You can build a data flow diagram for your threat modeling.
00:30:48.970 --> 00:31:06.673
Once you have all these flows, then you can leverage something like a policy or a rule engine to say, "show me all applications where sensitive data is being shared with third- parties," or show me all applications where we have a pixel, or show me all applications where there are cookies Any of these things.
00:31:06.673 --> 00:31:08.907
You can do so in a simplest way.
00:31:08.927 --> 00:31:24.797
Privacy code scanning - think of it as something which will scan the code of the application and build a data flow graph or a diagram out of it, focusing on specific lifec ycle cycle of data coming in, which is collection, and data going out, which could be sharing, storage, logging, processing in general.
00:31:24.797 --> 00:31:37.596
Once you have that, it should enable you to do all the core privacy use cases of RoPA documentation, privacy by design, finding privacy issues, and so forth.
00:31:37.999 --> 00:31:41.880
The main difference is that a security code scanner will not care about all of this.
00:31:41.880 --> 00:31:46.738
They don't care if the application is going to process personal data.
00:31:46.738 --> 00:31:49.661
If it has a security vulnerability, it has a security vulnerability.
00:31:49.661 --> 00:31:53.101
On the other hand, we do care about that; we only care about that.
00:31:53.161 --> 00:31:55.471
We don't care about if it has a security vulnerability.
00:31:55.471 --> 00:31:59.473
We only care about whether we accurately build this data flow graph.
00:32:00.302 --> 00:32:01.365
That is really helpful.
00:32:01.365 --> 00:32:12.590
I think it would be even more helpful to the audience if you could differentiate how does privacy code scanning and the data mapping capabilities of Privado.
00:32:12.590 --> 00:32:13.441
.
00:32:13.441 --> 00:32:13.441
.
00:32:13.441 --> 00:32:23.383
how is that completely different (because, I know that it is) from the traditional tools out there that do personal data discovery, correlation, data mapping - companies like BigID, Secuvy.
00:32:23.383 --> 00:32:24.445
ai, Securiti.
00:32:24.726 --> 00:32:26.971
ai, companies like that.
00:32:27.071 --> 00:32:27.312
Yeah.
00:32:27.312 --> 00:32:32.086
I would say, if you look at data discovery in general, it's basically discovering data at rest.
00:32:32.086 --> 00:32:46.484
What you're trying to say is, "hey, as a company, we've grown; and we continuously collected data, and then we kept on storing it, and now we don't have a good handle of where all of that is stored; which, from a security perspective, is important to secure the data.
00:32:46.484 --> 00:32:51.765
From a privacy perspective, it's important because you need to delete the data pieces, do retention, et cetera.
00:32:51.765 --> 00:33:08.849
So, a data discovery tool focuses on how quickly, at scale, with a good performance, I can go in and tell you where personal data is, in which data store, in which file, in which SaaS app.
00:33:08.849 --> 00:33:11.006
So, that's looking at data at rest.
00:33:11.006 --> 00:33:23.148
Now, the reason you need code scanning, even if you have a data discovery tool ( especially if you have a data discovery tool) is that a data discovery tool only gives you the picture of what data you have at rest.
00:33:23.148 --> 00:33:25.968
But, privacy is all about data use.
00:33:25.968 --> 00:33:29.804
It's about did you collect more data than you were supposed to?
00:33:29.804 --> 00:33:31.646
How did this data get used?
00:33:31.646 --> 00:33:37.067
A famous example was, a company was not fined because their phone number were breached or leaked.
00:33:37.067 --> 00:33:42.327
The company was fined because they collected phone numbers for authentication purposes, but were using them for advertising.
00:33:42.327 --> 00:33:47.331
That picture of how data gets used is actually in the code.
00:33:47.331 --> 00:33:51.425
It's actually in how you build a product, how you build an application.
00:33:51.425 --> 00:33:52.143
It's as simple as that.
00:33:52.163 --> 00:33:59.746
When you're doing a PIA, you're doing a PIA, not on the database; you're doing a PIA on a processing activity or a product function, or a product, or an application.
00:33:59.746 --> 00:34:07.245
We are doing it because you know privacy is about the full use of data - the collection point, the sharing point - and storage is one part of it.
00:34:07.245 --> 00:34:13.766
So, that's why you need to scan the code to get an automated understanding of how my data gets used.
00:34:13.766 --> 00:34:19.326
"Okay, I know it's in this database, but do you know which two products are connected to this one database?
00:34:19.326 --> 00:34:22.782
Do you know how that gets shared to a third party eventually?
00:34:22.782 --> 00:34:31.590
All of that information is written in code by engineers, version controlled and maintained, and that's why you need a code scanning solution.
00:34:31.590 --> 00:34:46.166
That's one answer, which is more around looking at the lifecycle of data, and their discovery solution only captures storage, whereas code scanning solution captures the complete lifecycle, especially if you're looking at engineering and products.
00:34:46.679 --> 00:34:54.085
The second argument on where these tools differ is the data discovery tools are looking at things when they've already entered your system.
00:34:54.085 --> 00:34:56.288
So, they've already collected the data.
00:34:56.288 --> 00:34:57.545
It's already in your system.
00:34:57.545 --> 00:35:03.668
That's when you're discovering "okay, yeah, now we have a new database which has these many data elements, right?
00:35:03.668 --> 00:35:04.844
Or we have this new file.
00:35:04.844 --> 00:35:17.429
" the code scanning solution - because they're super early in the lifecycle; we must shift left - this is when engineers just write in code to collect phone numbers for the first time, or precise location for the first time.
00:35:17.429 --> 00:35:21.927
You have not really pushed this to your production, which means it's not yet live.
00:35:21.927 --> 00:35:24.047
No customer data has ever flowed through that code.
00:35:24.500 --> 00:35:37.166
You can actually scan and discover all of these things at that time, which means if you want to get out of the cycle of a technical privacy debt, as you move left, through code scanning you can prevent some of these things.
00:35:37.559 --> 00:35:48.608
You can basically ensure that if you were not supposed to collect precise location, you're not collecting it, which means you have to do less scanning on the right side, where data discovery tools sit.
00:35:48.608 --> 00:35:52.465
You can also enforce better privacy standards, privacy engineering standards.
00:35:52.465 --> 00:36:03.485
When someone is creating a database, attaching it to your application code if that database table has sensitive data along with general identifiers, you can tell them not to do that.
00:36:03.485 --> 00:36:08.827
If they are going to share data with third parties, that's something you can catch early and fix as well.
00:36:08.827 --> 00:36:11.106
I would say these are the two main differences.
00:36:11.106 --> 00:36:19.887
One is from a coverage perspective - you do want to get clear line of sight into data sharing and data use, which is only available in the code.
00:36:19.887 --> 00:36:21.987
It's not available at the data storage layer.
00:36:21.987 --> 00:36:31.429
And I would say, second is moving left to fix and prevent things - find, fix, and prevent things rather than fire-fighting on the data side only.
00:36:31.429 --> 00:36:37.467
That's how privacy code scanning approach differs from a classic data discovery approach.
00:36:39.000 --> 00:36:41.889
I also want to highlight something.
00:36:41.889 --> 00:36:50.865
I am both an Advisor to Privado as well as an advisor to Secuvy because I definitely think that they are separate products that address separate issues.
00:36:50.865 --> 00:36:55.728
For companies today that are like w"We need to know where our personal data is.
00:36:55.728 --> 00:37:01.704
This wasn't a thing we needed to do and, in the big data era of collect everything, figure out a use for it later.
00:37:01.704 --> 00:37:04.539
It's sprawled across our environment.
00:37:04.539 --> 00:37:07.450
It's structured, unstructured, semi-structured data stores.
00:37:07.701 --> 00:37:08.605
Where is it?
00:37:08.605 --> 00:37:12.450
Because you can't protect any personal data if you don't know where it is.
00:37:12.450 --> 00:37:14.327
You can't delete it if you don't know where it is.
00:37:14.327 --> 00:37:19.505
You can't provide it to somebody and show them what you've collected about them if you don't know where it is.
00:37:19.505 --> 00:37:28.588
And so, I think it is absolutely important for companies in that space to use a data discovery, correlation, classification mapping tool.
00:37:29.059 --> 00:37:37.523
But, as you said, I want to see a world where everyone's using a privacy code scanner like Privado's, where you get your engineering best practices put in place.
00:37:37.523 --> 00:37:44.769
You embed privacy into the software development lifecycle, which is not the BigID, Secuvy, Securiti.
00:37:44.769 --> 00:37:46.567
ai tools are doing.
00:37:46.567 --> 00:37:52.690
They're looking more at the personal data lifecycle rather than embedding into the software development lifecycle.
00:37:52.690 --> 00:38:01.864
They are very different tools and I definitely think companies can use both, obviously depending on the maturity and whether or not you have the right resources to manage these tools.
00:38:01.864 --> 00:38:07.666
How does privacy code scanning enable engineering teams to stay compliant with new laws?
00:38:07.666 --> 00:38:21.126
I know you mentioned that before, but let's take, for instance, my state - Washington State's My Health My Data Act, which grants consumers the right to access, delete, and withdraw consent from the collection, sharing and processing of their health data.
00:38:21.287 --> 00:38:22.340
Yeah, absolutely.
00:38:22.340 --> 00:38:32.686
In fact, the My Health My Data Act is a classic example of where you do need to move to code to actually comply with the law, because it focuses on a couple of things.
00:38:32.686 --> 00:38:38.403
One of the main things it does focus on is use of data, like purpose of why you've collected it and how you're using it.
00:38:38.403 --> 00:38:40.346
So that is one.
00:38:40.346 --> 00:38:45.927
Sharing of health data is the most critical part there, and both of these things are in the code.
00:38:45.927 --> 00:38:47.465
So, take a health app.
00:38:47.465 --> 00:38:52.456
The first thing they would want for them to comply as a privacy or an engineering team.
00:38:52.456 --> 00:38:52.456
.
00:38:52.456 --> 00:38:52.456
.
00:38:52.961 --> 00:38:57.907
they will be asked "what health data you collect and who you share it with and how you use it.
00:38:57.907 --> 00:39:01.088
With Privado, you can basically connect in five minutes.
00:39:01.088 --> 00:39:22.684
We'll run a scan on all your code repositories and give you one single view of all the health data you're collecting; where that health data is flowing; and which products are using this health data, which means it solves all the three use cases of My health My - you you can, to do your consumers, consumers confidently say"This this is the health data that we collect, this is who we share it with.
00:39:22.684 --> 00:39:24.184
These are the service providers.
00:39:24.184 --> 00:39:33.891
If you are sharing it for any advertising reason, then you have to take authorization; and this is how all use cases we are using the health data for.
00:39:33.891 --> 00:39:35.224
So that's number one.
00:39:35.224 --> 00:39:36.766
So, you get to compliance faster.
00:39:38.364 --> 00:39:41.927
As I said, you don't have to spend months in figuring out this information.
00:39:41.927 --> 00:39:45.708
You can fix things rather remove certain health data flows.
00:39:46.139 --> 00:40:00.349
I think the second most important thing with the My Health My Data Washington Act is, if I remember correctly, there's a class action lawsuit, which means there is a very high onus on companies to prevent privacy issues from going to production.
00:40:00.590 --> 00:40:07.590
This means you do need a policy in your DevOps system, in your SDLC, looking for privacy issues.
00:40:07.639 --> 00:40:30.766
So, something needs to check for saying, "Hey, I pushed this code, I was using Google Analytics, but then I, incidentally or accidentally, actually started sending health data to Google Analytics because the page name has it or the search query had it, or I was intending to send only the user ID, but I sent this full object which has the health details as well.
00:40:30.766 --> 00:40:32.030
That's the second part.
00:40:32.030 --> 00:40:35.887
So one is like the initial compliance, which is your data maps, faster.
00:40:35.887 --> 00:40:40.903
You get the entire picture of health data collection, sharing ,and use - faster.
00:40:40.903 --> 00:40:56.144
And, second is guardrails - having these automated privacy checks for My Health My Data on behalf of privacy teams, which are not only looking for issues, but also providing a guidance to engineers on what to do right when they make a change.
00:40:56.144 --> 00:41:03.376
This will help you scale your program and actually, not only comply, but also remain in compliance with these laws.
00:41:04.642 --> 00:41:05.003
Awesome.
00:41:05.003 --> 00:41:05.826
Thank you for that.
00:41:05.826 --> 00:41:06.769
That's illustrative.
00:41:06.769 --> 00:41:13.307
All right, I want to talk a little bit about the future of Privado and just also privacy engineering education for a little bit.
00:41:13.307 --> 00:41:25.191
One of the things that really impresses me about Privado is that the founders focus on educating the next wave of privacy engineers is so important.
00:41:25.191 --> 00:41:47.451
Besides sponsoring this podcast, Robert Bateman's 'Privacy Corner', and, Vee, your own webinar series on privacy engineering, Privado recently made available a free Technical Privacy Masterclass hosted by Nishant Bhajaria, Privado's Advisor and Author of the seminal work 'Data Privacy: A Run Book for Engineers.
00:41:47.451 --> 00:41:50.387
' Can you tell us a little bit about this masterclass?
00:41:50.387 --> 00:41:51.744
Who was it designed for?
00:41:51.744 --> 00:41:53.724
What topics does it cover?
00:41:53.724 --> 00:41:55.664
How long does it take to complete?
00:41:55.664 --> 00:41:56.228
that kind of thing?
00:41:56.400 --> 00:42:02.621
That was such a fun project to build this course with Nishant on technical privacy.
00:42:02.842 --> 00:42:04.648
Again, the motivation for us was.
00:42:04.648 --> 00:42:04.921
.
00:42:04.921 --> 00:42:07.017
.it was also like an inward- facing motivation for us.
00:42:07.017 --> 00:42:35.369
It was like, "Hey, as we've been speaking and working with our customers, we end up working with a lot of technical privacy leaders and privacy engineers;" and some people have been in industry for a while, some are entering and I was like, is there some space where technical privacy leaders or privacy engineers can come together, Learn, talk, care, and that led to this one- by- one or multiple kind of initiatives, like starting with sponsoring a podcast.
00:42:35.369 --> 00:42:44.471
Then, as we went through that feedback cycle, working on this course, launching a community, doing our own webinars around this as well.
00:42:44.599 --> 00:42:49.152
It's been a great learning experience because I personally get to learn a lot doing.
00:42:49.152 --> 00:42:49.380
.
00:42:49.380 --> 00:42:55.128
.not just the masterclass but looking at questions in each webinar, listening to your podcast as well.
00:42:55.128 --> 00:42:55.327
Right?
00:42:55.327 --> 00:43:01.412
Specifically, on the masterclass, I mean it's for anyone who's working in a technology company.
00:43:01.633 --> 00:43:07.351
So, basically, we built it in such a way that it talks about why engineering is different.
00:43:07.351 --> 00:43:16.907
If you are in a tech company that has a lot of engineers, it starts with explaining how engineering has evolved and why it is different - kind of the same thing we were talking about initially.
00:43:17.440 --> 00:43:23.688
Then, it goes into how you can build a privacy program, which is kind of more aligned to how your engineering practices are.
00:43:23.709 --> 00:43:26.567
So, it's more proactive it actually kind of works.
00:43:26.567 --> 00:43:37.347
Then, we also went a little deep into how can you build a privacy tooling; how can you build your own DSAR; how can you buy or build a data discovery solution; and then, finally, goes into KPIs.
00:43:37.347 --> 00:43:41.590
It also has a nice bonus episode with Nishant's journey into privacy engineering.
00:43:41.590 --> 00:43:51.090
So, our core motivation was to help people who are entering or who are already, I would say are, 'Unofficial Privacy Engineers,' who are still doing the work.
00:43:51.090 --> 00:43:56.264
So, they can get a resource to begin with, and they can learn and enter the field.
00:43:56.264 --> 00:43:58.730
That was our motivation to do it.
00:43:58.730 --> 00:44:07.769
It's been a great experience launching this because we've got such an amazing feedback, both positive and also critical, on where we can improve.
00:44:07.769 --> 00:44:16.349
We have a lot of data points on the next modules we want to add and the version 2, how it could change, as well.
00:44:16.349 --> 00:44:19.688
But yeah, it was such a fun project to work on as well.
00:44:20.940 --> 00:44:31.351
I've been in privacy for over 18 years and even I learned new things from Nishant's perspective on how to approach implementing some of these solutions.
00:44:31.351 --> 00:44:37.392
I absolutely think - this is the best technical privacy class I've ever come across.
00:44:37.392 --> 00:44:38.945
I think it's excellent.
00:44:38.945 --> 00:44:41.809
I'm not raving about it simply because I'm a Privado Advisor.
00:44:41.809 --> 00:44:44.927
I think it's something that can be used by, well.
00:44:44.927 --> 00:44:45.288
.
00:44:45.288 --> 00:44:48.427
.anyone in privacy can take it; it's certainly aimed at technical folks.
00:44:48.840 --> 00:44:51.026
It would be great for engineering teams that are upskilling on privacy to take this.
00:44:51.026 --> 00:45:06.970
It would be great for current Privacy Engineering Managers to take this and take it with their teams, and maybe something they do as they talk about increasing their skills over the year, and being able to show the certificate that they've completed it.
00:45:06.970 --> 00:45:07.943
How long is it?
00:45:07.943 --> 00:45:09.387
I know I took it, but I wasn't sure.
00:45:09.387 --> 00:45:10.905
Is it like around 3 hours long?
00:45:11.420 --> 00:45:16.012
Yeah, roughly about anywhere from 2 - 3 hours is probably the content.
00:45:16.420 --> 00:45:18.726
It's somewhere between 2 - 3 hours.
00:45:18.887 --> 00:45:19.610
It's not a lot.
00:45:20.001 --> 00:45:21.985
This is kind of, as you said.
00:45:21.985 --> 00:45:23.269
.
00:45:23.269 --> 00:45:28.831
.probably like one third of people who attend our privacy engineering webinars are people who are trying to enter the field.
00:45:28.831 --> 00:45:30.845
For them, this is like a good primer.
00:45:31.467 --> 00:45:34.023
Some of them are actually software engineers who built.
00:45:34.023 --> 00:45:34.806
.
00:45:34.806 --> 00:45:50.170
.they literally have built a DSAR system in the company from ground up, like the full infrastructure; and now, they can actually learn the other parts of privacy, which is not just the tooling, but the wires in the house and you know how to think about it - a privacy program, KPIs, and stuff like that.
00:45:50.170 --> 00:45:57.992
So, yeah, that is the kind of audience that we have and, two to three hours - not a lot of effort, but a lot of learnings for sure.
00:45:58.800 --> 00:46:03.972
Oh, so much impact! So much wisdom dispensed by Nishant in that amount of time.
00:46:03.972 --> 00:46:06.526
So, it really does feel like a masterclass.
00:46:07.068 --> 00:46:10.528
You could be talking to experts, as well, in it.
00:46:10.528 --> 00:46:21.291
He's clearly talking in a way where both experts can step back and get more of a holistic perspective about what their approach is; but newbies to the field could also pick up those best practices immediately.
00:46:21.291 --> 00:46:22.766
So, it really is good.
00:46:22.766 --> 00:46:29.568
I'm going to put a link to it in the show notes so that anyone can check it out; and, remember it's free, so there's really no negative here.
00:46:29.568 --> 00:46:32.809
If you have the will, then Privado's provided the resource.
00:46:32.809 --> 00:46:35.287
I do want to know if you have numbers?
00:46:35.287 --> 00:46:36.289
How long has it been out now?
00:46:36.289 --> 00:46:37.144
Like a month or two?
00:46:37.581 --> 00:46:39.347
How many people have completed the course so far?
00:46:39.740 --> 00:46:47.099
About that - we are inching towards getting 1000 enrollments to the course.
00:46:47.099 --> 00:46:49.579
So, yeah, it's organically grown a lot.
00:46:49.579 --> 00:47:00.599
I mean, again, I'm super thankful to people who took the course, posted on LinkedIn, and gave good feedback because that encourages more people to take the course and then, you know, more people can learn about it.
00:47:00.599 --> 00:47:02.305
Because it's successful.
00:47:02.305 --> 00:47:02.566
.
00:47:02.566 --> 00:47:07.970
.again, as I said, the next version of it - at least for the people have taken it - we are going to go deeper.
00:47:07.970 --> 00:47:22.686
Like one is Technical Privacy Review - something that I'm really looking forward to create with different people, along with Nishant, something very specific which goes into, OK, how do you do a review?
00:47:22.686 --> 00:47:23.680
How should you design it?
00:47:23.680 --> 00:47:25.166
What should the KPIs be?
00:47:25.166 --> 00:47:31.159
" So, once we have this base where people have taken it, I think the next ones are going to be more in there.
00:47:31.159 --> 00:47:33.864
Ai governance is another one we are thinking about as well.
00:47:34.967 --> 00:47:35.791
Oh yeah, that makes sense.
00:47:35.791 --> 00:47:38.293
There's a lot of demand for knowledge there.
00:47:38.293 --> 00:47:43.230
So, I know that you've got some really exciting features on Privado's roadmap.
00:47:43.230 --> 00:47:45.090
Would you mind sharing a few of those with us?
00:47:45.432 --> 00:47:45.773
For sure.
00:47:45.773 --> 00:48:00.512
I think broadly, again, as I kind of laid out, our vision is to be the platform where privacy and engineering teams can come together, collaborate, and they can confidently ship features fast with privacy built- in from the get go.
00:48:00.512 --> 00:48:03.688
And once you have this vision, saying, "Ok, this is what we want to do".
00:48:03.688 --> 00:48:12.567
We want to enable speed - for the developer, it's a good experience with less privacy risk, better privacy experience for the end user.
00:48:12.567 --> 00:48:15.811
It really forces us to solve for some things.
00:48:15.811 --> 00:48:18.532
The first problem is this visibility problem .
00:48:20.146 --> 00:48:26.592
as As a privacy professional, if you're working in a technology company, one question if you want to answer is "I have this product, product A.
00:48:26.592 --> 00:48:29.610
Show me the data flow diagram of that.
00:48:29.610 --> 00:48:39.673
I mean, it's so hard to answer that question, even with all the work that has been done; even if you bought a privacy program management tool, did the data mapping, bought a data discovery tool.
00:48:39.673 --> 00:48:44.776
Still, you're not able to answer that because the tooling was not built to answer this question.
00:48:44.776 --> 00:48:54.912
So, our motivation, our vision, all the features that are coming up is "hey, we already probably solved the problem to a good extent, but it has to be super simple.
00:48:54.912 --> 00:48:58.173
Someone can answer this question really, really fast.
00:48:58.173 --> 00:49:09.831
And then, the next level is, for example, we can automate documentation like RoPA for 40% - 50%, and then now, we've just taken it up to even 70+% thanks to our language model.
00:49:09.831 --> 00:49:19.132
So, how can you use code - the source of truth - to build this documentation, which are evergreen, which are coming from the code, which have a lot of context as well?
00:49:19.132 --> 00:49:21.893
So, that's kind of the first big puzzle that we are solving.
00:49:22.545 --> 00:49:27.635
The second big puzzle we are trying to solve for is making privacy- by- design programmatic.
00:49:27.635 --> 00:49:30.411
A lot of efforts are done in.
00:49:30.411 --> 00:49:31.354
.
00:49:31.354 --> 00:49:38.974
.the entire privacy- by- design process is to do privacy reviews, which are super important to do at the design stage for large features.
00:49:38.974 --> 00:49:43.472
But, you can also go into a rabbit hole where you can continue to do them.
00:49:43.472 --> 00:49:48.333
You can really scale them up, which is where you do so many privacy reviews that you have zero rest.
00:49:48.333 --> 00:49:50.409
And then what?
00:49:50.409 --> 00:49:52.394
That reduces the development speed.
00:49:52.394 --> 00:49:59.394
That literally halts product innovation; and, in today's environment, if you are not innovating, your company is kind of suffering.
00:49:59.644 --> 00:50:10.572
So, how can you make it to a point where you're reviewing the right stuff and then a code scanning solution is taking care of everything else, and a part of it is the product?
00:50:10.572 --> 00:50:15.057
A larger part of it is also open sourcing these privacy rules that we have.
00:50:15.057 --> 00:50:17.894
So, a large part of work is happening there as well.
00:50:17.894 --> 00:50:19.411
I'm super excited about that.
00:50:20.025 --> 00:50:29.251
Then, I would say the third thing is going deeper into this full collaboration space of privacy and engineers and these technical reviews; and again, helping them scale up.
00:50:29.251 --> 00:50:50.934
So, we have an interesting product there as well, wherein we are kind of looking at stuff like PRDs, ERDs and trying to help people streamline or triage and say, "Hey, these are the five requests that you should definitely review and these are the ones that you can kind of safely ignore and let the privacy code scanner take care of it.
00:50:50.934 --> 00:51:01.630
" But again, overall vision is to have this one platform where these two personas can work together; and, for that, we have to solve for visibility, governance, and collaboration.
00:51:02.512 --> 00:51:02.793
Awesome.
00:51:02.793 --> 00:51:03.769
Thank you so much for that.
00:51:03.769 --> 00:51:11.713
Privacy engineering is a small but growing field, for sure; and you definitely have a front row seat to its development.
00:51:11.713 --> 00:51:15.751
You're working with customers from a variety of industries and of different sizes.
00:51:15.751 --> 00:51:21.590
Can you tell us what trends you're seeing in this space and how do you see the field shaping up over the next two years or so?
00:51:22.050 --> 00:51:26.070
Yeah, sure, I think the basic trend I'm seeing is it's becoming very popular.
00:51:26.070 --> 00:51:30.570
Companies have decided, and they're hiring privacy engineers.
00:51:30.570 --> 00:51:38.052
We run a Privacy Community where we post on our Job Board new jobs, and there are always new jobs almost every week.
00:51:38.052 --> 00:51:40.432
It is getting popular.
00:51:40.432 --> 00:51:43.052
So, that's a net positive trend, I would say.
00:51:43.724 --> 00:52:10.374
The second thing is, at least what I've seen, is Privacy Engineers are getting successful at their jobs, which means they are becoming successful in a company to actually take the amazing work of the privacy professionals - the Chief Privacy Officer, the Chief Legal Officer - have done on the policy side (on creating internal policies, best practices, record keeping) and translate them into engineering requirements and tools that they can use to scan, build, buy - all of that work.
00:52:10.374 --> 00:52:30.931
One of the simplest trends I'm seeing is existing Privacy Engineers are getting successful in reducing privacy risk; successful in building privacy features and tooling; and, hence, it's a nice cycle wherein because they're getting successful, they're going to newer companies and newer companies are hiring more Privacy Engineers and that's an amazing cycle.
00:52:30.931 --> 00:52:34.673
This one thing I'm seeing is there are more Privacy Engineers that are coming in.
00:52:34.673 --> 00:52:44.692
It's still a small community of people where everyone is super helpful, sharing information, and trying to network with each other to share best practices.
00:52:44.692 --> 00:52:45.956
It is growing.
00:52:45.956 --> 00:52:50.396
I think that's one trend that I'm seeing in the space.
00:52:50.664 --> 00:52:50.664
Awesome.
00:52:50.664 --> 00:52:52.893
How do you think it's going to shape up over the next two years or so?
00:52:53.125 --> 00:52:55.594
Again, I think it's just kind of mainstreaming.
00:52:55.594 --> 00:53:02.331
Mainstreaming would mean that we would have better KPIs for different things.
00:53:02.331 --> 00:53:06.849
I do think, for example, Nishant's book talks about KPIs for data discovery.
00:53:06.849 --> 00:53:13.068
I do think there will be KPIs for Technical Privacy Reviews or Privacy Engineering Assessments, which will become popular.
00:53:13.068 --> 00:53:31.349
I do think privacy code scanning will become mainstream, and that's what we've seen with our customers - the Privacy Engineers taking the lead because they would be the ones who will be like "Hey, we have this nice automated check as part of SDLC, which is looking for things, so we are doing high- level work, more important work in the company as well.
00:53:31.885 --> 00:53:45.764
I'm not sure about this, but I think the impact of AI governance, Privacy Engineers might also play a big role there, but that's so early that I don't really know for sure.
00:53:45.764 --> 00:53:51.405
Definitely, they'll have a big role to play, but I don't know how much they will end up owning that piece.
00:53:51.405 --> 00:53:51.405
.
00:53:51.405 --> 00:53:51.405
.
00:53:51.405 --> 00:53:55.974
I mean, it'll be a shared responsibility, but I don't know the exact answer to that.
00:53:55.974 --> 00:54:00.168
But at least, these are a couple of trends, or couple of ways, I can see the field shaping up.
00:54:01.132 --> 00:54:01.775
Thank you so much.
00:54:01.775 --> 00:54:06.777
Do you have any words of wisdom to leave the audience with before we close?
00:54:07.085 --> 00:54:14.336
No, I mean, I just wanted to come here on the podcast and share our journey and what we've been doing with Privado.
00:54:14.336 --> 00:54:19.311
Again, personally, we as a company are super grateful to the privacy community.
00:54:19.311 --> 00:54:25.713
I think privacy in general, I think are the most open people, most accepting people, most diverse people.
00:54:25.713 --> 00:54:33.134
Everyone is trying to solve the user's problem, which sounds super exciting because you're looking things from the user's angle.
00:54:33.134 --> 00:54:36.610
Obviously, you have the business metrics, but you're looking at things from the business angle.
00:54:36.610 --> 00:54:46.510
So, yeah, we're super appreciative and thankful to the entire privacy community for accepting us, and working with us, and giving us good and nice feedback and critical feedback as well.
00:54:46.510 --> 00:54:52.231
And, we really look forward to working with everyone who's listening on the podcast in the future as well.
00:54:53.125 --> 00:54:54.612
Yes, everyone, go check out Privado.
00:54:54.612 --> 00:54:57.795
I'll put the link in the show notes.
00:54:57.795 --> 00:55:07.554
Well, Vee, thank you so much for joining us today on The Shifting Privacy Left Podcast to talk about privacy code scanning, Privado, and the rise of privacy engineering.
00:55:07.554 --> 00:55:08.949
[Vaibhav: Thanks, Debra, for having me here.
00:55:08.949 --> 00:55:15.733
] Until next Tuesday, everyone, when we'll be back with engaging content and another great guest, or guests.
00:55:15.733 --> 00:55:21.153
Thanks for joining us this week on Shifting Privacy Left.
00:55:21.153 --> 00:55:23.490
Make sure to visit our website, shiftingprivacyleft.
00:55:23.490 --> 00:55:28.688
com, where you can subscribe to updates so you'll never miss a show.
00:55:28.688 --> 00:55:33.690
While you're at it, if you found this episode valuable, go ahead and share it with a friend.
00:55:33.690 --> 00:55:42.269
And, if you're an engineer who cares passionately about privacy, check out Privado: the developer-friendly privacy platform and sponsor of the show.
00:55:42.269 --> 00:55:43.989
To learn more, go to Privado.
00:55:43.989 --> 00:55:44.510
ai.
00:55:44.510 --> 00:55:48.614
Be sure to tune in next Tuesday for a new episode.
00:55:48.614 --> 00:55:49.385
Bye for now.
