( prologue )
kamsi ezenwa. privacy program professional. eight-plus years across ad tech, saas, consulting, and a federal privacy regulator. i turn privacy requirements into processes a company can run on an ordinary tuesday, not policies that only look good in a deck.
↓ the file continues( what i do )
most privacy programs fail in the same place: the gap between what the policy says and what the company actually does on a busy day. my whole career has been closing that gap. the programs i have run span us, canadian, and european rules: gdpr, ccpa/cpra and the us state laws, pipeda, quebec law 25, with working knowledge of hipaa and biometric privacy requirements. different laws, same job: a requirement only counts once it is a process someone actually follows.
two things worth knowing up front. i started at a federal privacy regulator (i investigated privacy complaints), so i know how a program looks from the other side of the table. and i am not a policy-only privacy person: if a task is repetitive, i automate it. three of the projects below are agents i built because the manual version was wasting the team’s week, or missing things outright.
this page is the work behind the resume. the resume has the full history; what’s here is what the problems were, what i built, and what changed. the awkward questions are answered further down, before you have to ask them.
( the work )
six projects. what was broken, what i built, what changed.
a global ad tech platform · program built from scratch
there was no reliable answer to the basic question (what personal data do we hold, where, and why), so i built the enterprise data inventory from scratch: a taxonomy the business could use, intake every business unit actually completed, first complete version in about four months. everything else in the program stood on it.
a global ad tech platform · automation over manual work
rights requests used to run on memory and inboxes, each one carrying a legal deadline. i automated intake and fulfillment with power automate and the onetrust api: audit trails, sla tracking, and metrics leadership could read, designed in from the start. deadlines became visible before they became problems.
a global ad tech platform · ai governance, by doing it
keeping up with regulatory and platform changes used to mean a person checking dozens of sources by hand, and things got missed. i built a monitoring agent with an ai agent, running on azure functions, that tracks the sources, deduplicates what it finds, and delivers a digest, so the team hears about changes when they happen, not after they become incidents.
a cloud saas company · regulated environment
the customers are law firms, and what they put in the product is their clients’ legal lives. i worked on the consumer rights workflows and the enterprise data map in onetrust, supported the hipaa compliance program, and assessed vendors: operations that leave evidence, in a product where trust is the whole business.
a global ad tech platform · finding the work privacy never heard about
assessments depended on teams volunteering their projects, and the reluctant ones just didn’t. i built an agent that searched confluence for projects containing words like “personal data”, “pii”, and “sensitive data”, and flagged the ones that needed a privacy impact assessment, early enough that controls could be designed in, not bolted on after launch.
a global ad tech platform · benchmarking against the market
a program grading its own homework will always pass. i built an agent that tracked privacy updates from competitors in the industry, good and bad, and cross-checked them against our own practices, surfacing where they were doing something better, and where their mistakes were a warning we should check at home.
( interlude: the writing )
short, practical pieces on the laws that come up in almost every privacy interview, and on the parts of the work that decide whether a program holds up.
pipeda’s replacement has been “coming” for years. legitimate interests, data mobility, algorithmic transparency, and penalties aimed at boards, and why the right move while it is still in parliament is prepare, don’t panic.
while ottawa debated, quebec legislated. mandatory privacy impact assessments, breach notification to the commission, privacy by default, penalties with teeth. law 25 quietly became the standard the rest of canada builds to.
four risk tiers, one very consequential definition of high-risk, and a compliance clock already running. the companies that will struggle are not the ones with risky ai. they are the ones that cannot produce a list of their ai at all.
most ai privacy problems are data problems wearing a model costume. start with what flows into the system, not the model, and do it at the design stage, while things can still change.
a consent banner records a choice. what matters is whether that choice survives the trip to every tag, partner, and platform supposed to honour it. test the plumbing, not the banner.
counting activity makes a program look busy. the numbers i trust: rights deadlines, how much gets assessed before launch instead of after, and how old the open findings are.
( the process )
the same five moves, in the same order, on every program i have run.
you cannot protect, retain, or delete data you cannot describe. so the first job is always the map: what personal data exists, where it lives, who owns it, how long it stays. everything else is built on that answer or it is built on sand.
an assessment at the design stage is a conversation. the same assessment a week before launch is a fight. i push privacy into the build process. and when teams won’t bring the work to privacy, i build things like pia catcher that go and find the work.
if a person has to remember to do it every week, it will eventually be missed, and in privacy a miss can be a compliance gap. monitoring, routing, reminders, record-keeping: if it repeats, a system should carry it, and people should spend their time on the judgment calls.
five or six metrics, reviewed on a regular cadence, each one tied to a decision someone might actually make. if a number has never changed a conversation, stop reporting it. and check the program against the market, not just against its own plans.
incident command is part of the job, not an interruption of it. breach assessment, the notification calls (who gets told, what, and by when), and tabletop exercises that find the gaps in the plan while they are still hypothetical.
( before you ask )
every interview ends up at these questions eventually. here they are up front, answered the way i’d answer them in the room.
anyone who wants privacy as decoration. if the job is rubber-stamping decisions after they’re made, writing policies nobody reads, or producing a binder that exists so someone can say a binder exists: don’t hire me, we’ll both be miserable. i ask awkward questions early, when they’re still cheap. if that sounds like friction to you, it will feel like friction every week.
pretending. i can’t sell a program i don’t believe is working, and i won’t tell leadership things are fine when the metrics say otherwise. i’m also bad at leaving a broken process alone because “that’s how it’s always run”, if it wastes the team’s time every week, i will keep bringing it up. and to be precise about the edges of the role: i’m not a lawyer, so i don’t give legal opinions, and i’m not a security engineer. i work best with both in the room.
early and close to the builders. give me a real problem, access to the product and engineering people, and a mandate to fix things rather than just flag them, and i’ll do the best work of the team. small team, big scope, clear owner. that’s the setup i’ve done my best work in. what doesn’t work: being brought in the week before launch to bless something, or privacy as a ticket queue nobody reads.
i’ve sat on every side of this table. i investigated complaints at a federal privacy regulator, i advised clients as a consultant at a consulting firm, and i’ve run programs in-house at a cloud saas company and a global ad tech platform. so i know how your program reads to a regulator, to a customer doing diligence, and to the employee who has to actually follow it. the other part: i build. when the monitoring was manual and things got missed, i didn’t write a memo about it. i built the tool. it’s project no. 03.
( curtain call )
questions about any of the work on this page, or a program you need built: the fastest way to reach me is email.
happy to discuss any of the projects above in a conversation: what the problem was, what i’d do differently, and what i’d refuse to do again.
if it doesn’t run on a tuesday, it doesn’t run.