Sri Lanka's Personal Data Protection Act is written for lawyers. This is the engineering translation — the concrete things that have to exist in a codebase before a compliance review goes well.
1. A lawful basis, recorded per purpose
Every piece of personal data you process needs a reason, and the reason has to be recorded against the specific purpose. “The user signed up” is not a basis for running a credit check. Model consent as its own record — subject, purpose, timestamp, mechanism, expiry — and make the processing code require one before it will run.
2. Retention that actually deletes
A retention policy in a Word document is not a retention policy. It needs to be a scheduled job that finds expired records and removes or irreversibly anonymises them, plus a report you can show that proves it ran.
3. Data-subject requests as a feature
- Access — export everything you hold about one person, in a readable format
- Rectification — correct it, and propagate the correction downstream
- Erasure — delete it, including from backups and analytics, or explain the legal reason you cannot
- Objection — stop one kind of processing without deleting the whole account
If answering these takes an engineer with database access, you will answer them late. Build the endpoints.
4. Security proportionate to sensitivity
Encryption at rest for identifiers and financial data, access controlled by role and logged in a tamper-evident way, secrets kept out of source control, and a breach-notification path you have actually rehearsed rather than merely written down.
5. Know who your processors are
Every third party that touches personal data on your behalf needs a written processing agreement and a place on a register you maintain. That includes the analytics tool somebody added last quarter.