More and more folks want to hire privacy engineers. This is great! You almost certainly need them! But, just like security, privacy engineering is a whole field.

So for the folks who want to hire or become a privacy engineer, a rundown of the current rough types I see. (Big)

First off, let's talk about the two things that people want out of a privacy engineer: (1) privacy-respecting products and systems, (2) compliance.

Compliance is making sure that all the correct paperwork is filled out showing that you followed the rules. Here's the thing...

Compliance is necessarily reactive. It's responsive to failures of the past. If you're doing new things, then you're likely to hit new failure modes. For you, compliance isn't going to be sufficient. Because when things go really wrong, no one cares about paperwork.

Proactive privacy engineering looks at how the world is changing and your strategic direction to help shape your products and systems to better support your users and the folks affected by your systems.

There are a lot of skillsets involved here, and I'm going to try to list a rough categorization. I may forget some, please remind me if I did. (I need a post-vaccine nap!)

(1) Analysis/consulting. These folks look at your product/system (or better yet, the plans you have to build one), ask questions, find failures before they happen, and help you design in a way to robustly avoid those failures.

So, for example, someone comes to me with a new feature and I ask:
* How can the user delete this information and is it really deleted?
* Oh, hey, if we put this nifty crypto in there, we can avoid collecting this information at all. Does that open up abuse vectors?

Privacy analysis/consulting folks have a skillset somewhat akin to security reviewers, but usually with a heavier emphasis on how humans of various stripes interact with each other and your product. They may well audit code. Requires specialized skills.

(2) Privacy products. This is where you're building the parts of privacy that users can see, like account deletion pages, interfaces that let users see and control their data, etc.

Note that most privacy affordances should be part of the main product; this is specialized stuff.

Folks who work on privacy products are generally the same sorts of folks who work on any other features of your product: build user interfaces, build infrastructure, do UX or product management. Requires privacy understanding, but not always deeply specialized. Some should be!

(3) Math & theory. Need to do anonymization? Need to analyze whether there's some kind of funky joinability risk across all your datasets? Need to figure out what's going to happen when you delete part of that datastore that you're being kicked you into cleaning up? Math.

Working on the more mathematical end of privacy requires specialized math training; if you already have a good theory background it's very learnable. If not... hard going. Do not try to hire someone and throw them into doing this without training.

Note that I've thrown a lot of non-overlapping specialities in here, like anonymization and deep data analysis. Make sure you know what you want before interviewing these folks, because they're not fungible.

(4) Infrastructure. If you've got infrastructure, you probably need privacy infrastructure. For instance, when you want data to be deleted, you need a system to kick that off and then monitor it. You need access control. Probably something around cookies. Etc.

Privacy engineers who build infrastructure have the infrastructure-building software engineering skills as well as knowledge of privacy. Teaching interested infrastructure engineers privacy skills is very doable and it's a tricky, interesting systems problem.

(5) Tooling and dashboards. You might have a data deletion or access system, but how the heck do you have humans understand what's going on in there or get access? Tooling! Also extremely useful for things like efficient, accurate analysis and review of systems, etc.

Engineers who work on tooling and dashboards for privacy need to know privacy, metrics, and how to build user interfaces. Bonus points for a knowledge of communication -- failure mode is not building for what you want your user to *do* and instead just "telling people things".

(6) User experience. This is part of privacy engineering, though it's not considered part of software engineering. There are three major sub-fields here: research, design, and writing.

UX design, you probably know. I call it out UX writing here because writing small pieces of text which clearly communicate tricky (and legally sensitive!) things, sometimes when the user is already upset, is *hard*. Having lawyers do this is not generally recommended.

UX research uses qualitative and quantitative methods to study people and how they interact with a product. While there are many excellent general UXRs, I recommend someone with a specific privacy background, esp. someone who can work ethically with marginalized populations.

(7) Privacy policy. This isn't always done by privacy engineers, but I strongly recommend having someone with privacy engineering skills in the mix. It's very easy to write aspirational policy or policy which doesn't work with systems as they are. Both of these are bad.

Privacy engineers who do policy must have clear writing, understand a bunch about compliance and privacy regulation, but also should understand how data is processed and systems are built and run by an organization, so they can build a bridge to improving practices.

(8) Privacy process. Process design is key to getting things done but isn't a privacy engineering skill on its own. I'm including it here because some privacy engineers have it in tandem with one or more of the above skills and holy crow if you don't have it around it's not good.

Some people can do more than one of these things. I know literally no one who can do all of them well. (... my UX mocks have inspired well-deserved tears of laughter) So when you say you want to hire a privacy engineer, figure out what type you need and advertise for *that*.

I seem to have run out of Tweets in this thread, so I'll leave this here. I've been asked how to interview privacy engineers; that will be a thread for another day. If you have other questions, drop them here and I'll do my best to answer.

As @alexanderjaeger pointed out, I totally missed incident and vulnerability response! You definitely need this!

Incident responders need a cool head, excellent communication skills, and knowledge of how things go wrong in privacy.