This article is provided for informational purposes only and does not constitute legal advice. It reflects publicly available sources as at 18 September 2026. Organizations should consult qualified legal professionals regarding the interpretation or application of the Personal Data (Privacy) Ordinance (Cap. 486) and other applicable regulations.
Most privacy work fails at the same point. Not at design - teams are usually willing to talk about principles early. It fails at the gate: the moment a release goes out and nobody can say, in evidence, what changed about the personal data it touches.
A privacy review that produces a document is easy. A privacy control that produces a record every time you ship is harder, and it is the only one that survives an audit.
This article covers the second kind. It is about what has to be true before a system goes live, who signs it, and what artifact proves it. If you are earlier in the cycle and still deciding how the system should be built, start with our companion piece on what PDPO means for your data architecture and come back to this one when you have something to ship.
Design decisions are reversible on a whiteboard and expensive in production. Release is the last moment where both of these are true at once: the system is real enough to test, and small enough to change.
It is also the only point that repeats. A platform gets designed once and released two hundred times. If your privacy controls live in the design review, they age out within a quarter. If they live in the release gate, they apply to every change, including the ones nobody thought were privacy-relevant - a new logging field, a cache added for performance, a support tool given read access to fix an incident.
Three things make a release gate work, and all three are engineering problems rather than policy ones:
It is binary. The gate either passes or it does not. "Mostly documented" is a fail.
It produces an artifact. A ticket, a signed checklist, a pipeline record. If the only evidence is that someone remembers reviewing it, there is no control.
It is owned by the team that ships. A gate owned elsewhere becomes a queue, and queues get bypassed under deadline.
The Privacy Commissioner's Office published guidance in August 2026 on the use of agentic AI, and it comes with a security checklist organised by lifecycle stage: evaluation, preparation, deployment, use, and uninstallation. That structure is useful well beyond agentic systems - it maps cleanly onto how software actually gets shipped and retired.
What follows takes those five stages and states, for each, what must be true and what artifact proves it.
The question at this stage is not "is this allowed" but "do we know what we are taking on".
Must be true:
The personal data the system will process is listed, by field, with a stated purpose for each.
Someone is named as accountable for that data - a person, not a team.
Any third-party component that will see personal data is identified, including model providers and plugin or tool vendors.
If a vendor processes personal data on your behalf, the contractual position is recorded. Note that direct regulation of data processors is among the amendments currently under discussion rather than in force, so the contract is doing the work here.
Artifact: a one-page data note attached to the project, not a paragraph in a slide deck. It should be short enough that it stays current.
Common failure: the list covers the primary database and misses everything downstream - the analytics export, the support tool, the spreadsheet someone maintains.
Must be true:
Non-production environments use masked, synthetic, or de-identified data, or the exception is documented and time-boxed.
Access to production personal data is role-based and reviewable; the current list of who holds it can be produced on request.
Retention periods are defined for every store the system will write to, including logs, caches, and derived tables.
For AI components: the provenance of training and fine-tuning data is recorded, and prompt or completion logging is a deliberate decision with a retention period attached, not a default that was left on.
Artifact: