PDPA and SME systems: an engineering checklist (not legal advice)

The Personal Data Protection Act is a legal framework; this post does not replace counsel or your DPO. It addresses what we see break in delivery: systems that collect fields “just in case,” exports that land in uncontrolled inboxes, and retention that nobody owns. Good engineering reduces risk by design—not by hoping staff remember policy PDFs.

Data minimisation in forms and APIs

Every field you store is a field you may need to locate, correct, or delete on request. Challenge optional fields: do operations truly need them, or did a form inherit them from an old template? The same applies when integrating third parties—pull the minimum viable attributes and document why each exists.

Access control that matches real roles

Clinic, HR, and retail teams often ask for “everyone can see everything” for speed. That rarely ages well. Role-based access should mirror how authority works on the ground: branch vs HQ, clinician vs admin, payroll vs line manager. Technical enforcement beats policy posters.

Retention and backups

Backups are not infinite free storage—they are copies subject to the same questions as production. Align retention windows with how long the business truly needs each category of data, and make sure restore drills do not resurrect data that should have been purged. Your vendor contracts should say who can touch what in a hosted environment.

Audit trails that people will actually use

• Who viewed or exported sensitive records—and when.
• Who approved changes to master data (pricing, patient flags, salary bands).
• Immutable logs for events that regulators or insurers care about, without logging noise that hides signal.

If you are scoping a new system—especially in healthcare, HR, or finance—bring privacy questions into discovery early, alongside features. We build custom platforms where the workflow and the audit story are first-class; if you want a sanity check on architecture, start with a consultation.