CIPT
Privacy engineering as a job: who the CIPT is for

Privacy law tells an organization what it must do with personal data. Somebody still has to build the systems that do it: decide which fields are collected, how long they live, who can see them, how they are de-identified, and what a consent screen actually asks. The CIPT is the IAPP's credential for those people. This guide is about who they are, the legal duty that makes their work necessary, what the exam covers, and how it differs from the security and privacy credentials around it.
The facts here come from the IAPP's CIPT page and the CIPT Body of Knowledge, version 4.0.0, the IAPP's Certification Candidate Handbook and certification FAQs, the Official Journal text of GDPR Article 25, the European Data Protection Board's Guidelines 4/2019, and our CIPT Exam Guide. Where this page and the IAPP differ, the IAPP wins.
What does a privacy technologist do?
The IAPP says the CIPT proves you understand how to use technical solutions to build data protection into products and services. Its Body of Knowledge splits that into five domains and 16 competencies, with a range of items for each domain:
| Domain | Items | Competencies |
|---|---|---|
| I. The privacy technologist's role in the context of the organization | 15 to 19 | Legal and procedural roles (5 to 7); technical roles (5 to 7); privacy risk models and frameworks (1 to 3); data ethics and data privacy (2 to 4) |
| II. Data collection, use, dissemination and destruction | 19 to 23 | Minimizing privacy risk in collection (8 to 10), use (6 to 8) and dissemination (4 to 6) |
| III. Privacy risk management | 17 to 21 | Intrusion and decisional interference; software security; tracking and surveillance; workplace technologies; monitoring and managing risk |
| IV. Privacy by design | 7 to 9 | Privacy by design principles (4 to 6); privacy risks in user experiences (2 to 4) |
| V. Privacy engineering and privacy governance | 9 to 11 | Privacy engineering objectives (6 to 8); privacy-related functions and controls (2 to 4) |
The data life cycle is the heart of it. Minimizing privacy risk during collection is the single largest competency, at 8 to 10 items, and collection, use and dissemination together carry 19 to 23. That reflects a simple point: data that was never collected cannot leak or be misused. The risk management domain is close behind, and it is the most technical part of the exam: software security, tracking and surveillance techniques, workplace technologies, and the threat of intrusion and decisional interference.
The first domain is a reminder that a technologist works inside an organization. Legal and procedural roles and technical roles carry 5 to 7 items each: knowing who decides what, and where engineering responsibility starts and stops. Data ethics appears too, with 2 to 4 items on the connection between data ethics and data privacy, because not every harmful use of data is unlawful.
The legal duty behind the job
In the EU, privacy engineering is not optional. Article 25(1) of the GDPR says that, taking into account the state of the art, the cost of implementation, the nature, scope, context and purposes of processing, and the risks to people's rights and freedoms, the controller "shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner."
Article 25(2) adds the default rule: the controller shall implement measures ensuring that, by default, only personal data necessary for each specific purpose are processed. That obligation, the Regulation says, "applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility," and by default personal data must not be made accessible to an indefinite number of people without the individual's intervention. The European Data Protection Board's Guidelines 4/2019 explain how supervisory authorities read the Article.
Those sentences describe engineering work. Choosing the means of processing is a design decision. Pseudonymization is a technique. Collection limits, retention periods and access defaults are configuration. The CIPT is the IAPP's credential for the people who make those decisions well, and for anyone who has to show that an organization has met Article 25 by design rather than by luck.
Who builds privacy into systems?
Privacy engineering is rarely one job title. It is a set of responsibilities spread across the people who design and build systems. Read against the competencies, they fall into these roles:
| Role | Privacy decisions they make | CIPT competencies that carry the day job | Pairs it with |
|---|---|---|---|
| Privacy engineer | Design reviews, threat models, privacy-enhancing technologies | II data life cycle; III risk management; V engineering objectives | CIPP for the region |
| Software engineer or architect | What is collected, stored, logged and shared | II.A collection; II.B use; IV.A privacy by design | CISSP |
| Security engineer | Encryption, access control, secure development | III.B software security; V.B functions and controls | CISSP |
| Data engineer or data scientist | Pipelines, retention, de-identification, analytics releases | II.B use; II.C dissemination | AIGP for AI work |
| Product manager | Which features exist and what they ask of users | IV.B user experience; I.D data ethics | CIPM |
| UX or service designer | Notices, consent flows, settings and defaults | IV.B user experience | CIPM |
| IT and workplace technology lead | Monitoring tools, device management, employee systems | III.D workplace technologies | CIPM |
The pairings are our suggestion, not the IAPP's. The CIPT is about building; the CIPP credentials are about the law in a region, the CIPM about running the program, and the CISSP about security across the board. An engineer who works on personal data every day may want the CIPT plus one of those.
What the job looks like in numbers
No US occupation code covers privacy engineering. Most of the people who do it are counted as software developers or as information security analysts. O*NET gives these figures from Bureau of Labor Statistics data:
| Measure | Software Developers (15-1252) | Information Security Analysts (15-1212) |
|---|---|---|
| Employment | 1,717,800 (2025) | 192,900 |
| Median annual wage, 2025 | $135,980 | $129,180 |
| Projected growth, 2025 to 2035 | Much faster than average (7% or higher) | Much faster than average (7% or higher) |
| Projected job openings, 2025 to 2035 | 95,300 | 14,100 |
Neither code is privacy engineering, and we found no official count of privacy engineers. The table shows where the people who build privacy into systems are counted, and how large those occupations are.
When does the CIPT start to matter?
Privacy engineering work tends to arrive at a few predictable moments.
A new product handles personal data
Article 25 applies at the time the means of processing are determined, which in practice is the design review. If privacy is first considered at launch, the cheapest options, not collecting a field, setting a short retention, keeping a default closed, are already gone. An engineer who can lead a privacy design review saves the expensive rework later.
Analytics or data sharing is planned
Releasing data or statistics raises de-identification questions, and the CIPT expects candidates to know the techniques and their limits. Our guide defines them precisely. A dataset achieves k-anonymity if every combination of indirect identifiers appears at least k times. A system provides differential privacy if the output of a query stays virtually unchanged whether or not any one person's data is included; global differential privacy collects raw data centrally and adds noise only when queries run. Fully homomorphic encryption allows computation on encrypted data but is computationally intensive. Choosing among them is a design decision with privacy, utility and cost trade-offs.
A product adds tracking, monitoring or AI
Tracking and surveillance techniques, workplace technologies, and AI all appear in the risk management domain. Our guide uses Helen Nissenbaum's idea of contextual integrity to explain why some data flows feel wrong even when they are lawful: information moves out of the context in which it was shared. For AI training data, applying privacy-enhancing technologies such as differential privacy is one of the options the guide discusses.
The workplace gets new tools
Workplace technologies have their own competency. Employee monitoring tools can log keystrokes, capture screens and track physical locations, and our guide's approach is to evaluate each such tool for transparency and proportionality, applying the core principles of transparency, data minimization and purpose limitation to HR data. The same competency covers the privacy threats introduced by everyday communication systems and automated decision-making engines. An IT lead rolling out a new collaboration or monitoring platform is making privacy decisions whether or not anyone calls them that.
Profiling, intrusion and decisional interference
The risk management domain also asks how to minimize the threat of intrusion and decisional interference: systems that intrude on people or steer their choices. The practical skill is selecting technical controls that prevent behavioral profiling where it is not justified. A training or gaming platform that tracks behavior, for example, calls for clear transparency notices and restrictions on profiling, and an engineer is often the first person in a position to build those restrictions in.
A consent flow is redesigned
User experience has its own competency. A dark pattern manipulates a user into granting broader consent than they intend, and the IAPP's Body of Knowledge treats that as a privacy risk, not a design flourish. The person who designs the consent screen is making a privacy decision.
The design needs a threat model
Security threat models do not find every privacy harm. Engineers use privacy-specific frameworks such as LINDDUN to evaluate a design, alongside risk models such as the NIST Privacy Framework. Our guide's summary is that by learning frameworks from Nissenbaum and Calo to FAIR, NIST and the OECD principles, a candidate gains the tools to evaluate system designs objectively.
What each design decision asks of the CIPT
Here is Article 25 turned into engineering decisions. For each part of the Article, the second column is the design decision it creates, and the third is the CIPT competency that teaches it.
| Article 25 requirement | The engineering decision | CIPT competency (items) |
|---|---|---|
| Measures at the time the means of processing are determined (25(1)) | A privacy design review before build, with decisions recorded | IV.A privacy by design principles (4 to 6) |
| Measures such as pseudonymization (25(1)) | Which identifiers to replace, tokenize or remove, and where the key lives | II.B data use (6 to 8); V.A engineering objectives (6 to 8) |
| Data minimization in an effective manner (25(1)) | Which fields are collected at all | II.A data collection (8 to 10) |
| Only necessary data processed by default (25(2)) | Default settings, opt-ins, and what is turned on for a new user | IV.B user experience (2 to 4) |
| Limits on storage period (25(2)) | Retention rules and deletion jobs | II data life cycle, including destruction |
| Limits on accessibility (25(2)) | Access control and sharing defaults | II.C dissemination (4 to 6); V.B functions and controls (2 to 4) |
| Risks of varying likelihood and severity (25(1)) | A privacy threat model and risk monitoring | III.E monitoring and managing privacy risk (3 to 5) |
Vendors are part of the same picture. The technical roles competency includes evaluating the technical controls of third-party vendors, because a system that is well designed in house can still leak personal data through a supplier's API, analytics library or support tool. A design review that stops at the edge of the organization's own code misses that risk.
We have turned the table into a design review checklist that an engineering team can run at any design review, which you can copy or download below.
Privacy design review checklist for engineers
Privacy design review checklist for engineers
Use this at the design review of any feature that touches personal data. It follows GDPR Article 25 (data protection by design and by default) and the domains of the IAPP CIPT Body of Knowledge, version 4.0.0. It is an engineering aid, not legal advice; your privacy team decides what the law requires.
Purpose and data
- The purpose of the feature, in one sentence, agreed with the product owner
- Every personal data field listed, with why the purpose needs it
- Fields that are not needed removed before build (data minimization)
- Sensitive or special-category data flagged for the privacy team
By default (Article 25(2))
- Only the data necessary for each purpose is processed by default
- Collection, extent of processing, retention period and accessibility each set to the minimum by default
- Personal data not made accessible to an indefinite number of people without the person's own action
By design (Article 25(1))
- Measures chosen with the state of the art, cost, the nature, scope, context and purposes of processing,
and the risks to people in mind
- Pseudonymization or anonymization considered, and the choice recorded
- If releasing data or statistics: de-identification method chosen (for example k-anonymity or
differential privacy) and its limits understood
- Encryption in transit and at rest, and who holds the keys
Threats
- A privacy threat model of the design (for example LINDDUN), not only a security one
- Tracking and surveillance techniques in the feature identified and justified
- Software security risks that would expose personal data reviewed with the security team
User experience
- Notices and choices placed where the person makes the decision
- No dark patterns: consent flows do not push people into broader consent than they intend
- Rights requests (access, deletion, correction) can be fulfilled for this feature's data
Evidence
- Design decisions recorded, with the privacy reasons
- Controls tested, not only described in policy
Where does the credential apply?
The CIPT is not tied to one country's law. Its subject is technique: how to minimize collection, de-identify data, design defaults and model privacy threats. Those techniques serve the GDPR's Article 25 in Europe, and they serve the reasonable-security duties in US state privacy laws, as well as sector rules and contracts. The IAPP runs the exam at Pearson VUE test centers and online through OnVUE, and describes the CIPT as ANAB-accredited.
A design review checklist travels the same way. The questions it asks, what is collected, why, for how long, who can see it, what the defaults are and what the threat model found, are the same whether the system serves users in Paris or Phoenix. What changes is the legal threshold the privacy team applies to the answers.
That neutrality is the CIPT's strength and its limit. It will teach an engineer how to build privacy into a system wherever the system runs. It will not tell them what a specific law requires; for that, the organization's privacy counsel and the CIPP credentials do the work.
What the CIPT is not
It is not a coding exam. It tests design decisions and the understanding of techniques, not the ability to implement them in a particular language or framework. Nobody sitting it is asked to write code, so it is open to product and design people too.
It is not a security credential. Security and privacy overlap, and software security has its own competency, but the CIPT's center is what data should exist and how it may be used, not only how to protect it.
It is not a law exam. The first domain covers legal and procedural roles, so an engineer knows who decides what, but the law itself is the CIPP's subject.
It is not a policy credential. Our guide warns against confusing policy with evidence. A written policy that says data is minimized is not evidence that it is; a schema, a configuration and a test are.
What does it take to earn and keep?
| Item | The IAPP's rule |
|---|---|
| Accreditation | ANAB-accredited designation |
| Exam | 90 questions in 2.5 hours, at a Pearson VUE test center or online through OnVUE |
| Pass | 300 on a scale of 100 to 500 |
| Upkeep | IAPP membership or a certification maintenance fee, and continuing privacy education under the IAPP's CPE policy |
Current fees and exam-day rules are on our CIPT exam page.
How does it compare with the credentials around it?
| Credential | The question it answers | Suits |
|---|---|---|
| CIPT | How do we build privacy into technology? | Engineers, architects, data and product people |
| CIPM | How do we run the privacy program? | Program managers and privacy leads |
| CIPP/E | What does European data protection law require? | DPOs, counsel and anyone handling EU personal data |
| CISSP | How do we secure the organization across eight domains? | Security practitioners, architects and leaders |
The CIPT sits between the law and the systems. A privacy team works best when the CIPP holder can say what the law requires, the CIPM holder can run the program, and the CIPT holder can build it. An engineer who already holds the CISSP will find the CIPT adds the privacy-specific techniques security training leaves out. Our CIPM exam page and CISSP exam page cover the alternatives.
What will the exam expect of you?
The CIPT has 90 questions in 2.5 hours, 1 minute 40 seconds a question on average, with a pass mark of 300 on the IAPP's scale of 100 to 500. Questions often describe a system or a design and ask which choice minimizes privacy risk, which technique fits, or which role should decide.
Precision about techniques wins marks. Know the difference between pseudonymization and anonymization, between k-anonymity and differential privacy, and between global and local differential privacy. Know what a privacy threat model finds that a security one misses. And watch for the trap our guide names: confusing policy with evidence. An option that says "update the policy" can be wrong when the problem is a system that collects too much.
Test yourself with the CIPT quiz, see the domains on one page in the CIPT mind map, and if the credential is part of a job move, the CIPT interview questions page covers what employers ask.
How to prepare
Start from the Body of Knowledge, which is what the exam is written to, and give the data life cycle and risk management domains the most time: together they can carry 36 to 44 items. If you plan 60 hours, the midpoints of the ranges suggest roughly 14 for the technologist's role, 17 for the data life cycle, 15 for risk management, 6 for privacy by design and 8 for engineering and governance, before you adjust for your background.
The CIPT Exam Guide (Wikidata) has 17 chapters across 516 pages, mapped to all five domains and all 16 competencies and weighted to the published item counts. It is written for engineers, not lawyers, and every claim traces to a primary document.
The CIPT Practice Questions (Wikidata) has 200 questions weighted to the published item counts, each with a rationale that says why the right answer is right and why every wrong option fails. The answer letters are spread evenly across A, B, C and D on purpose.
Engineers often prepare best by working from their own systems. Take a feature you know well and run it through each domain: who decided what, what is collected and why, how the data is used and shared, what the threat model would find, what the defaults are, and which controls prove it. The gaps you find are the parts of the Body of Knowledge to study first, and the exercise doubles as the design review your team should have run anyway.
Is it current? Both books follow Body of Knowledge 4.0.0, effective 1 September 2025. If the IAPP publishes a new version, check its effective date against your exam date.
So, do you need the CIPT?
Take it if you design or build systems that handle personal data and you want to show you can build privacy into them: as a privacy engineer, a software engineer or architect, a security or data engineer, a product manager or a UX designer. It is the IAPP's credential for the people who turn Article 25 and its equivalents into schemas, defaults and design reviews.
It also suits the engineer who has become the team's privacy person by default: the one asked whether a field can be logged, whether a dataset can be shared with a partner, or whether a new analytics tool is allowed. The CIPT gives that role a structure and a recognized standard.
Take the CIPM instead if your job is running the program, and a CIPP if it is the law. And if you are a security engineer who already holds the CISSP, the CIPT is the natural next step for the privacy side of the systems you secure.
Questions people ask about the CIPT
Who is the CIPT for?
People who build privacy into products and systems: software engineers and architects, privacy engineers, security engineers, data engineers and scientists, product managers and UX designers. The IAPP says the CIPT proves you understand how to use technical solutions to build data protection into products and services.
Is the CIPT a technical exam?
It is a technologist's exam rather than a coding test. It asks how to minimize privacy risk across the data life cycle, how privacy risk models and threat frameworks work, and how techniques such as de-identification, encryption and privacy by design apply, all at the level of design decisions.
What does the CIPT cover?
Five domains in Body of Knowledge 4.0.0: the privacy technologist's role (15 to 19 items), data collection, use, dissemination and destruction (19 to 23), privacy risk management (17 to 21), privacy by design (7 to 9) and privacy engineering and governance (9 to 11).
How many questions are on the CIPT exam?
The IAPP's certification FAQs give the CIPT as 90 questions in 2.5 hours. You sit at a Pearson VUE test center or online through OnVUE.
What is the CIPT passing score?
300 on the IAPP's scale of 100 to 500.
What legal duty does the CIPT relate to?
In the EU, GDPR Article 25 requires controllers to implement appropriate technical and organizational measures for data protection by design and by default, both when deciding the means of processing and during the processing itself. The CIPT teaches how engineers meet duties like that.
CIPT or CIPM?
The CIPT is for building privacy into systems; the CIPM is for running the privacy program around them. An engineer takes the CIPT; a program manager the CIPM.
CIPT or CISSP?
The CISSP covers security across eight domains. The CIPT covers privacy: minimizing collection, de-identification, tracking, consent design and privacy threat models. Security protects data; privacy engineering decides what data should exist and how it is used. An engineer working on personal data can benefit from both.
Do I need to know privacy law for the CIPT?
Enough to understand the legal and procedural roles around you. The first competency covers legal and procedural roles and responsibilities, but the CIPT is not a law exam. For the law, the IAPP offers the CIPP credentials.
Which CIPT Body of Knowledge is current?
Version 4.0.0, effective 1 September 2025. Check the IAPP's CIPT page before you book.
CIPT: test yourself in five minutes
Which books prepare you for the CIPT exam?

Certified Information Privacy Technologist. 17 chapters, 516 pages.

Practice questions with full rationales, weighted to the published blueprint. 216 pages.
How to credit this page
Using a figure or a passage from this page in an article, a course, a forum answer or AI-generated text? Please credit Credential Press and link to this page, so your readers can check the source and the date it was reviewed. Copy a ready-made citation:
Plain text
Markdown
HTML
Sources
- IAPP, CIPT: Certified Information Privacy Technologist
- IAPP, CIPT Body of Knowledge and Exam Blueprint, version 4.0.0, effective 1 September 2025
- IAPP, Certification Candidate Handbook: scoring scale and passing score
- IAPP, Certification FAQs: exam length
- Regulation (EU) 2016/679 (GDPR), Article 25
- European Data Protection Board, Guidelines 4/2019 on Article 25 Data Protection by Design and by Default
- NIST, Privacy Framework
- LINDDUN privacy threat modeling
- O*NET OnLine, 15-1252.00 Software Developers (BLS data)
- O*NET OnLine, 15-1212.00 Information Security Analysts (BLS data)
Credential Press is not affiliated with, endorsed by or authorized by the IAPP or ISC2. CIPT, CIPM and CIPP/E are trademarks of the International Association of Privacy Professionals; CISSP is a trademark of ISC2.