Core Competencies of Privacy Practitioners
Introduction
Privacy practitioner job titles are confusing and all over the place.
What's the difference between a privacy analyst, privacy engineer, privacy architect, privacy program manager, or privacy attorney? Honestly, who knows?
Privacy practitioners with the same title often do wildly different work.
These differences in responsibilities vary based on the maturity and needs of the organization, size of the privacy team, and the composition of the team itself. In mature organizations, you may be hyper-focused on a particular topic, e.g., anonymization. In nascent organizations, you may be responsible for the entire privacy program.
It's often more productive to talk about core competencies rather than job titles.
So what are these competencies?
Defining Core Competencies
Every privacy practitioner shares some balance of the same core competencies.
These competencies represent broad categories of knowledge and expertise. However, they do not describe any specific job duties, tasks, or requirements.
The exact balance of these core competencies varies from role to role.
For example, a privacy engineer likely requires more technical expertise than a privacy attorney. However, both roles require some amount of technical expertise, e.g., understanding what anonymization means and its practical implementations and limitations, and trade-offs.
This post presents a practical mental model for the type of knowledge required to be an effective privacy practitioner. In some particular order, these competencies include:
These competencies overlap. Don't get too hung up on this.
Privacy Expertise
Privacy expertise is the main reason we get paid to do what we do 😄
Privacy attorneys should know the source of privacy requirements, differences between privacy laws and regulations in different jurisdictions, how to write a data protection impact assessment, transfer impact assessment, etc—you get the idea.
Privacy analysts should know a little about these things, but not obsess over them. They're likely more operational and focus on issue triage, privacy reviews, third-party risk management, reviewing and categorizing cookies, etc.
The type and amount of expertise depends on your role, but may include:
- Interpreting laws, regulations, and requirements
- Writing policies, standards, and guidelines
- Deployment of privacy controls and guardrails
- Operationalizing effective review and documentation processes
- Topic-specific knowledge (pseudonymization, anonymization, cookies, etc.)
Whatever your specific task or role, you must apply a privacy lens to all decisions.
Technical Expertise
The needs of the organization will define what "technical" means for you.
Technical skills may mean software engineering, system design, understanding cloud infrastructure, data analysis, deploying and configuring privacy vendors, etc.
There's no right or wrong answer here—they're just different.
What technical expertise should you have? Well, the answer depends on the specific role, size of company, maturity of privacy program, type of industry, etc.
Do you need someone to implement an anonymization library? What about deploying a vendor to automate cookie compliance or data subjects' rights? What about building these mechanisms in-house for a mature organization?
You don't have to be a software engineer to be a technical privacy practitioner. You can understand cloud infrastructure, database schemas, review code, understand ETL pipelines, etc. all without writing a lick of code.
Some technical expertise may even be more general problem-solving skills and technology agnostic. For example, whether you understand data structures and algorithms, can apply critical, analytical, or logic-based thinking.
These are valuable skills if they align with the needs of your organization.
Communication
Ask any privacy practitioner how to be effective and they'll say communication.
We talk to people every hour of every day. You will answer questions like, what is privacy? How does it differ from security? Why can't I retain this data indefinitely?
Without communication, teams won't know what the right thing is or how to do it. Clearly articulating requirements is essential for achieving good privacy outcomes.
You should understand and acknowledge teams' pain points—often in relation to privacy processes and requirements. If you put in the work to understand the businesses' needs, space, and pressures, you can approach every communication opportunity with a partnership mindset and ultimately build trust.
Ineffective communication leads to:
- Worse privacy for data subjects
- Failure to build trust with stakeholders
- Privacy requirements become privacy suggestions
- Products will launch lacking appropriate review or guardrails
- Teams will push implementation timelines for privacy controls
If you don't have buy-in from the organization, you may as well call it a day.
Program Management
How do you operationalize privacy requirements? Program management.
In privacy, program management takes output from other competencies, e.g., privacy and technical expertise, and incorporates them into business processes.
Knowing when, where, and what privacy reviews entail is one thing. Developing an effective privacy review program that integrates with the business needs and expectations is an entirely distinct skill set.
You can develop libraries, tools, and provide ad hoc consultation on anonymization. However, to drive business adoption requires you to build and manage a wider anonymization program.
You can't have effective privacy processes without program management.
Risk Management
Nothing in privacy is perfect—you must make trade-offs and manage risk.
This is not a pedantic diatribe about different risk types, how to manage and reduce them, etc. That's certainly important, but not for this discussion 😄
Businesses often will not drop all priorities to remediate privacy issues.
A product team may want privacy approval 3 days before launch. They may say they shouldn't implement privacy controls because their application is being deprecated. They may have a reasonable reason for just not doing things.
Whatever the reason, you must be able to manage these risks.
Every time you provide a privacy requirement to a product team, you are managing risk. When you write an anonymization policy, you are managing risk. When you prioritize some product launches over others, you are managing risk.
Managing risk and making trade-offs is a core part of being a privacy practitioner.
Business Acumen
You don't need an MBA, but you must be able to understand the business.
Privacy programs don't exist in isolation. Rather, they exist to safeguard people, their data, and enable the business to operate appropriately and efficiently.
To be effective, you must have some business acumen. Some examples:
- What does your business do?
- What is the software development lifecycle?
- What adjacent functions exist, e.g., security and risk?
- What complementary or contrasting requirements exist?
- What privacy risks are more inherent to your line of business?
Failure to consider the business context will lead to ineffective privacy processes.
If you're developing a new privacy review process, when and where should you engage the business? Should you tie-in to their existing engineering design review process? Is there even a consistent design process across teams and organizations?
Business acumen helps you build trust and effectively integrate with your business.
Wrapping Up
We sincerely hope this post was accessible, useful, and practical for you. If you have any feedback on this post, please let us know. Cheers.
