Skip to main content
Orion Five Engineering

10 Jalan Kilang #04-05, Singapore 159410
+65 6100 5505

Book a scoping call
← All insights

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.

Terence Kok · 2026-08-26 · 4 min read

A brushed steel rack of thin white plates standing on edge like index cards, a red index tab clipped to the front plate and the rearmost plate sliding out of the back of the rack.

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

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 policyRetention in the data layer
A document says records are deleted after six monthsA scheduled job deletes them, and logs that it did
Someone runs the purge, when they rememberThe purge runs whether anyone remembers or not
An auditor interviews the administratorAn auditor runs a query for the oldest record and reads the date
A departing employee takes the procedure with themThe procedure is in the schema, and the schema stays

What to specify before build

  1. Every class of personal data the system will hold, and the purpose that justifies each one.
  2. For each class, the event that ends the purpose — deactivation, delivery, incident closure — and the period after it.
  3. Where the purge runs, what it logs, and how a reviewer confirms it ran.
  4. 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.

Read next


All insights