Nishant Bhajaria's Data Privacy: a runbook for building privacy processes before handover

Neil Hunt, Netflix’s former chief product officer, writes in a publisher’s blurb for the book that he wishes he had had it at Netflix in 2015 or 2016. It is promotional copy, but it makes a fair point: privacy knowledge is worth most when it arrives early.

For a forward deployed engineer, early or late usually shows at handover. You have wired the pipeline to real data and the demo runs well, then the client’s legal team starts asking: who can see which column, what happens when a user asks for their data to be exported or deleted, where is consent stored?

Without answers, the deployment stalls. Data Privacy: A runbook for engineers by Nishant Bhajaria, published by Manning in 2022 and 384 pages long, was written for exactly that moment. Manning’s tagline is blunt: build privacy into system design.

Where has the author sat?

According to Simon & Schuster, Bhajaria led technical privacy work at Uber, Netflix and Google, including a role as head of privacy engineering at Netflix. A KDnuggets feature produced with Manning says the book teaches how to deploy privacy solutions and tools at scale.

The same piece stresses the balance between strict data protection and business needs. That is a weekly tug-of-war for FDEs: the client wants to ship fast, legal wants certainty. The book also teaches how to build a privacy programme that can win budget from senior leadership, which is a skill of persuasion, not just of writing code.

What order does the table of contents teach?

The table of contents on Bookshare shows the book following the rhythm of a real programme. Part 2, on proactive data governance, has three linked chapters: classification, inventory, then data sharing.

Part 3, “Building tools and processes”, covers technical privacy reviews in chapter 6, data deletion in chapter 7 and data export for DSARs in chapter 8. Part 4 closes with consent, security vulnerabilities, and chapter 11 on scaling, hiring and regulation.

The order is worth noting: first know what data you hold, then build the tools, and leave organisational questions for last. A good engagement follows the same rhythm.

Classify first, write the pipeline second

Manning lists classifying data by privacy risk among the skills the book teaches. Everything downstream rests on this step: who gets access, how long data is kept, what must appear in an export or a deletion.

Take a hypothetical example: you are deploying a forecasting system for a delivery company. The orders table holds the order ID, order value, recipient phone number, GPS coordinates and delivery notes; the figure at the top of the article labels each column.

The column most easily overlooked is the notes. It is a free-text field, so people type names and home addresses into it, and it must be rated high risk however harmless it looks.

Once the labels exist, many decisions make themselves. The forecasting model probably has no need for phone numbers, so that column never enters the feature store. First-week task at the client: draw up the label table and ask their data owner to confirm it.

Reviews exist to make you faster

Manning says the book teaches how to set up a technical review process that speeds up the Privacy Impact Assessment, and chapter 6 is devoted to it. The framing is worth keeping, because engineers tend to see privacy review as a brake.

One way to apply it: bring a ready-made one-page template recording what data is used, why it is needed, who has access and how long it is kept. When the questions already have a structure, legal only has to check rather than investigate. Ask at the outset for the name of the person who will approve the review, so you are not hunting for them at the last minute.

Deletion, export and consent are features to hand over

Two consecutive chapters on deleting and exporting data, plus a section on designing a consent management platform (CMP), show that the author treats these as tools to build, not clauses on paper. With a DSAR, when a person asks to see their own data, the system has to find every copy.

Back to the delivery company: one recipient’s GPS coordinates might sit in the source table, in precomputed features and in logs. If every request means writing a script by hand, that is a debt you leave behind for the client.

The root of the solution lies in the inventory step in Part 2: a catalogue stating which table holds user_id in which column, with its risk label. A minimal export function only needs to read that catalogue, query each table by user_id, and bundle the results into one file for the requester, along with a list of the sources scanned.

The deletion runbook reuses the same catalogue. For each table, write one line: hard delete, anonymise or wait for the retention period to lapse, who runs it, and how to verify that a query by user_id now returns nothing. A new table that is not in the catalogue is not yet cleared for production.

Are 384 pages worth the time?

Readers are split. On Goodreads the book scores 4.27 from 15 ratings, a small sample. Some praise it lavishly and argue that IT leaders should make it required reading; one complains it is so long-winded it took ages to finish; another calls it shallow.

Those two complaints suggest a sensible way to read it: as a runbook to consult, not cover to cover. Read Part 2 in your first week at a client, chapter 6 before the first ship, and chapters 7 and 8 plus the consent section when preparing for handover. Save chapter 11 for when you lead several engagements.

The book suits FDEs deploying on real personal data best, and software engineers who want to move into FDE work but have never sat at the same table as legal. When reading job descriptions, watch for phrases such as data governance, PII or consent.

On a CV, do not write a vague “familiar with privacy”. Write how many tables you labelled for risk, which client you built a deletion or export flow for, and how much shorter the review cycle became.

Neil Hunt wished he had had this book a few years earlier. FDEs have an advantage he lacked: they can be in the room from day one, before sensitive data has a chance to flow into the system.