AI governance
Retention is a design decision. Write it into the data layer
A retention policy that lives in a document is a promise. One that lives in the schema is a fact. The bunkering system at PSA Marine purges a face record six months after the account is deactivated because the purge is part of the system, not part of a procedure someone has to remember.

Executive summary
6 months
after deactivation, an account and its face record purge automatically
5 years
fuel transaction reports are retained
30 days
CCTV footage is held before it is overwritten
Core conclusions
- Retention is three separate clocks on three kinds of data, and the right answer for each is different — which is why a single policy sentence never covers it.
- The PDPA's Retention Limitation Obligation is met by the system deleting data when the purpose ends, not by a document saying it will.
- Written into the data layer, retention turns an audit from an interview into a query.
Most retention policies are honest at the moment they are written and untrue within a year. Not because anyone lied, but because a policy is a promise that somebody will run a procedure, and procedures depend on the person who remembers them still being in the job.
The biometric fuel management system at PSA Marine's Brani and West Coast bases has run continuously since 2019. It authenticates a launch master by face before fuel flows. That makes it a system holding biometric data about identifiable people, in a security application, for a critical-infrastructure operator — about the most demanding retention case a Singapore integrator will meet. The way it handles retention is worth setting out because it is not a policy at all. It is a design.
Three clocks, one system
- Identity: a deactivated account and its face record purge automatically six months after deactivation. The biometric exists only as long as the person it authenticates is still authorised.
- Transactions: fuel transaction reports are retained for five years. That is the operational and financial record, and it outlives the identity that created it.
- Surveillance: CCTV footage is held for 30 days. Long enough to investigate an incident once it is known about; not long enough to become an archive of everyone who walked past.
- Around all three: access follows least privilege, so the question of who can see a record is answered by role before it is answered by retention.
What the obligation actually asks for
The PDPA's Retention Limitation Obligation is simple to state: cease to retain personal data as soon as it is reasonable to assume the purpose for collecting it is no longer served by keeping it. The difficulty is not the principle. It is that 'as soon as' is a clock, and a clock has to be running somewhere.
Biometric data raises the stakes. The Personal Data Protection Commission's guidance on the responsible use of biometric data in security applications treats it as data warranting a higher standard of protection, precisely because a face, unlike a password, cannot be reissued once it leaks. A six-month purge tied to deactivation is the answer to that: the system holds the fewest faces it can, for the shortest time it needs to.
Policy versus design
| Retention as a policy | Retention in the data layer |
|---|---|
| A document says records are deleted after six months | A scheduled job deletes them, and logs that it did |
| Someone runs the purge, when they remember | The purge runs whether anyone remembers or not |
| An auditor interviews the administrator | An auditor runs a query for the oldest record and reads the date |
| A departing employee takes the procedure with them | The procedure is in the schema, and the schema stays |
What to specify before build
- Every class of personal data the system will hold, and the purpose that justifies each one.
- For each class, the event that ends the purpose — deactivation, delivery, incident closure — and the period after it.
- Where the purge runs, what it logs, and how a reviewer confirms it ran.
- The one class that must outlive the others, and why: usually the transaction record, kept for a financial or regulatory period the identity record does not need.
A retention rule the system enforces is the only kind that is still true after the people who wrote it have moved on. Everything else is a good intention with a date on it.


