Adding a privacy review to a tracking project

This is not a process somebody invented to slow projects down. The Office of the Privacy Commissioner's privacy management program guidance says assessments should be required throughout the organization for all new projects involving personal information and on any new collection, use or disclosure of personal information.

The same section adds the reason, and it reads like something written by people who have watched this fail: the OPC says it has seen instances of organisations offering new services that collect, use or disclose personal information that had not been thoroughly vetted from a privacy perspective, and notes that fixing a privacy problem after the fact is costly.

It also names the mechanism. Organisations should develop procedures for conducting such assessments and develop a review and approval process that involves the privacy officer when designing new initiatives, services or programs.

So the ask is a gate with an owner, applied at design time. What it is not is a document produced after the tags are live. A tracking project that reaches the review with a container already published has skipped the part where the review could have changed anything.

The failure I see most often is a policy that says every project needs privacy review, which produces a queue, which produces a bypass. Trigger conditions have to be specific enough that a delivery lead can answer yes or no without asking anybody.

Any new tag, pixel or SDK added to a site or app. Any new field on a form. Any new identifier joined to an existing dataset. Any new destination for existing data, including a new report shared outside the organisation. Any new vendor that will receive data. Any change to what a consent banner asks or does.

Notice what is not on that list. Renaming an event, changing a dashboard filter, or fixing a broken trigger for an event already approved does not need a gate. Keeping the trigger list short is what keeps the gate credible.

The regulator's framing supports drawing the line at collection, use and disclosure rather than at effort. A one-hour change that sends a new field to a third party is in scope. A two-week refactor that changes nothing about what leaves the browser is not.

Six questions. That is the whole form. The point is not to produce a document, it is to force somebody to say out loud what a field is for before it exists.

The purpose question is the one that does the most work, because the limiting collection principle turns on it. Schedule 1 of the Act is direct about it: organizations shall not collect personal information indiscriminately, and both the amount and the type of information collected shall be limited to that which is necessary to fulfil the purposes identified. A field nobody can justify at design time is a field that will be justified after the fact, which is the mechanism behind how personal data ends up in your analytics without anyone deciding to put it there.

The consent question needs a specific answer rather than a category. Which signal, set where, and what does the tag do when the signal is absent. The policy argument about consent signalling is settled elsewhere, in what consent mode v2 actually changes; the gate's job is only to confirm somebody has decided and that the decision is implemented.

The access question is the one teams cannot answer, and that is the value of asking it early. The OPC's guidance for businesses says you must respond to an access request within 30 calendar days, so if nobody can name the systems that would have to be searched for one person's data, the project is adding to a problem that already has a clock attached to it.

Before build, not before launch. A review that lands after a container is published can only produce rework, and rework is the fastest way to teach a team that the gate is an obstacle.

In practice that means the gate sits between the ticket being groomed and the ticket being pulled. It becomes an entry condition, which is the same mechanism as any other entry condition and is worth designing alongside your definition of ready rather than as a separate approval workflow nobody remembers.

Give it a service level. Two business days is achievable for the six questions above and is short enough that nobody argues. A gate with no stated turnaround is a gate that becomes a bottleneck, and a bottleneck becomes a bypass within about a quarter.

Name one approver and one backup. The OPC guidance is explicit that for larger organisations the privacy officer should be aware of the review process and directly involved where initiatives are high risk. In an agency or a mid-market marketing team that usually means one person owns the gate and escalates the small number of items that are genuinely sensitive.

And write down who approved what, with the date. The OPC's accountability bulletin is clear that an organisation shall designate an individual or individuals who are accountable for its compliance with the principles in Schedule 1, and a review with no signature on it does not connect to anybody.

Testing verifies that the thing you built works. The gate asks whether it should exist. Those are different failures and they need different checks.

A form field capturing a date of birth because the CRM template shipped with one will pass every test. A conversion label appended to a URL that then flows into an analytics property will pass every test. A third-party chat widget that sets its own identifiers will pass every test, because from the browser's point of view nothing is broken.

The gate also catches the accumulation problem, which no single test can see. Each addition is defensible on its own and the combined dataset is more identifying than any of its parts, which matters because identifiability is assessed on the result of a join rather than on the inputs. That is the specific reason a marketing data warehouse needs a documented purpose per table rather than a general intention to keep the data available.

None of this replaces verification. The engineering question of whether the implementation does what the written position claims is separate, and it is usually where the real gap sits. Tracking that behaves differently on a campaign landing page than on the main site is the failure pattern that survives launch QA, and it can make a correct privacy review untrue three weeks after it was signed.

The gate will be tested by a campaign that needs to launch on Thursday. Decide now what happens then, because deciding in the moment always produces the same answer.

The version I use is a conditional pass: the tag ships, the six answers are recorded as provisional, and the ticket carries a fixed date by which they are confirmed or the tag is removed. That keeps the record honest, which is the part that matters, without pretending a marketing team will hold a launch for a form.

Review the log quarterly rather than the individual entries. The pattern in the log tells you more than any single review did. If the same question is unanswered every time, the problem is upstream of the gate.

The OPC's guidance frames a privacy management program as something that is never finished and that requires ongoing assessment and revision, and says program controls should be monitored, periodically audited and where necessary revised. A gate designed once and never examined is not evidence of a program, it is a form.

One boundary. This describes a delivery process built around what published guidance asks for. It is not legal advice, and whether a particular collection is appropriate in your circumstances is a question for counsel. The gate's job is to make sure that question gets asked while it is still cheap to act on the answer.