Description

A focused course, tailored for you

Sri Lanka PDPA in Your Code: A Working Engineer's Course

Implement consent, subject-access, retention and breach logic in the codebase you already ship, mapped clean to GDPR for export clients.

Your team has to make the application PDPA-ready and the senior advice is still slide decks. You need to ship the schema migration, the DSAR endpoint, the retention cron and the breach notification template into the actual codebase this quarter.

$199 one-time

Tailored to your situation. Access within 24 hours. 30-day money-back.

Includes a hand-built implementation playbook delivered alongside course access, generated for your specific situation.

Why this course

Sri Lanka's Personal Data Protection Act came into force under the Personal Data Protection Commission, and controllers are now in the registration window. For working software engineers at small Colombo shops with export clients in the UK, Australia and Europe, the question stops being "what does the Act say" and starts being "what changes in the repo, what migrations run, what endpoints get added, what gets logged, what stops being logged." Legal will hand the team a one-page summary. The engineering decisions sit with you and your tech lead. Without a clean code-first walkthrough, teams either over-engineer (a homegrown consent platform nobody maintains) or under-engineer (a checkbox on a form, no audit trail, no deletion path). Both fail the first vendor review from a UK customer asking for a GDPR Article 28 attestation.

What you walk away with

Ship a PDPA-compliant consent capture and revocation workflow in a real application database.
Stand up a working DSAR endpoint that returns the export the regulator expects, with audit logging.
Implement retention windows and a soft-delete to hard-delete state machine the team can maintain.
Wire incident detection and the PDPA 24-hour notification workflow into your existing error tracker.
Map every PDPA control you implement to its GDPR equivalent so the same codebase passes UK and EU vendor reviews.

The 12 modules

Module 1. PDPA for engineers: the parts that change your repo

Read the Personal Data Protection Act through the lens of the codebase, not the law firm. We name the eight specific obligations that translate into code changes: lawful basis, consent, purpose limitation, retention, subject access, rectification, erasure and breach notification. Each one is mapped to the database tables, API endpoints, logging configuration and operational runbooks it touches. You leave with a one-page change list you can paste into a Jira epic that day.

Module 2. Personal data inventory: what your application actually holds

Before any code changes, build a real inventory. We walk through inspecting the schema, ORM models, log streams, third-party SDK payloads and analytics events to catalogue every field that qualifies as personal data under the PDPA definition. Output is a YAML inventory file the team commits to the repo, used as the source of truth for every later module. Covers special category data and pseudonymisation choices.

Module 3. The consent table and the consent state machine

Design and implement the consent table: columns for subject_id, purpose, lawful_basis, captured_at, revoked_at, source, version_of_notice. Walk through the state machine from prompt to capture to revoke, with the queries you will run for the PDPC's record-of-processing requirement. Includes the version-of-notice pattern so a policy text change does not silently invalidate prior consent.

Module 4. Building the DSAR endpoint

Implement /api/dsar from request through verification to delivery. Identity verification via existing auth, queue handling so the synchronous request does not block, the JSON export schema the PDPC expects, redaction of third-party data, audit trail of who served what when. Includes the rejection path for unverified requests and the deadline-tracking logic so the 30-day clock never silently slips past.

Module 5. Soft-delete, hard-delete and the right to erasure

Most applications soft-delete and stop. The PDPA right to erasure means hard-delete with verifiable removal across replicas, backups, analytics warehouses and downstream pipelines. We implement the state machine: request, queue, replication confirmation, backup window expiry, hard-delete, audit row. Includes the special case where deletion is refused on legal-hold grounds and how to document the refusal so the regulator accepts it.

Module 6. Retention windows in code, not in policy documents

Retention is a cron job, not a paragraph in a PDF. Implement a retention manager that reads the inventory from Module 2, applies the configured window per data class, and either archives, anonymises or deletes. Includes the dry-run mode the team will need before flipping it on in production, and the alerting that catches when records age out of retention without the job firing.

Module 7. Logging, observability and keeping PII out of stdout

Most PDPA exposure in small engineering teams is in the log streams. Implement a structured logging policy that names which fields are loggable, which are masked, which are dropped. Configure your error tracker (Sentry, Rollbar, equivalent) to scrub PII before transmission. Includes the test pattern: a CI check that fails the build when a logger emits a field flagged in the inventory.

Module 8. Third-party processors and data processing agreements in your stack

Every cloud database, email provider, analytics SDK and queue you use is a processor under the PDPA. We walk through cataloguing them, requesting the DPAs, and adding the technical controls the contracts assume: regional pinning, encryption at rest, access scope, sub-processor disclosure. Covers the small Sri Lankan shop's most common gap, which is the analytics SDK that exfiltrates PII to a US warehouse with no DPA on file.

Module 9. Breach detection, the 24-hour clock and the notification artefact

The PDPA expects controllers to notify the PDPC of a personal data breach within 24 hours of becoming aware. Implement the detection: error tracker filters, unauthorised access alerts, suspicious query patterns. Implement the workflow: incident channel, severity grading, scope assessment, draft notification, sign-off. Output is a notification template prefilled from incident data so the on-call engineer does not write it from scratch at 3am.

Module 10. GDPR mapping for UK, EU and Australian export clients

Your Colombo shop's revenue often comes from UK retailers, EU SaaS, Australian government suppliers. Map every PDPA control implemented in Modules 3 to 9 to its GDPR Article and APP equivalent. Output is the vendor-review one-pager the lead can send to a UK customer's procurement team, showing the same codebase already meets GDPR Articles 6, 7, 15, 17, 30 and 33, plus the Australian Privacy Principles equivalents.

Module 11. The technical attestation pack for vendor reviews

When the UK or EU customer asks "how do you handle personal data", the vendor review questionnaire arrives. Assemble the attestation pack: the inventory from Module 2, the architecture diagram showing data flows, the DSAR runbook from Module 4, the retention schedule from Module 6, the DPA register from Module 8, the breach notification template from Module 9. Includes the cover note that wins the procurement reviewer's trust.

Module 12. Operating the controls: handover, on-call, and quarterly review

Compliance is not a project, it is a steady cadence. Walk through the on-call runbook for PDPA incidents, the quarterly inventory refresh job, the retention dry-run review, the consent-table reconciliation, the DPA register check. Includes the small-team pattern: how a two-engineer shop runs all of this without a dedicated DPO, and what gets escalated to outside counsel when the situation crosses the legal-judgement line.

How this addresses your situation

Specific modules that map to what you said you are dealing with.

The lead asks how the application handles a data subject access request. Modules 4 and 5 give the endpoint and the deletion path.

A UK customer's procurement team sends a 60-question vendor review on data handling. Module 11 gives the attestation pack.

The team realises the analytics SDK has been quietly exfiltrating personal data for two years. Module 8 gives the catalogue and the DPA workflow.

An unauthorised access alert fires at midnight and the on-call engineer is the one drafting the regulator notification. Module 9 gives the prefilled template.

What you get with this course

Twelve written modules, each with a worked implementation example in a small-team stack.
Schema migrations for the consent table, the audit table, and the DSAR queue.
A DSAR endpoint scaffold with identity verification and queue handling.
A retention manager cron template with dry-run mode.
A logging-policy configuration and a CI check that enforces it.
A DPA register template and an analytics SDK audit checklist.
A breach notification template prefilled from incident data.
A vendor-review attestation pack template with PDPA-to-GDPR mapping.
A 30-day money-back guarantee.
The hand-built implementation playbook, tailored to your stack, delivered with course access.

What you will have in hand by Day 1, Week 1, Month 1

Within 24 hours: account provisioned in the Art of Service learning environment, all twelve modules available, downloadable templates accessible.

Day 1 to 14: work through Modules 1 to 6, ship the inventory file, the consent table, the DSAR endpoint scaffold and the retention manager into a development branch.

Day 15 to 28: work through Modules 7 to 12, ship the logging policy, the DPA register, the breach notification template and the vendor-review attestation pack.

Day 30 onward: quarterly review cadence from Module 12 keeps the controls operating without dedicated DPO headcount.

Before and after

Before

You can describe the PDPA in conversation but you cannot point to a single repository change that proves the application implements it. The next UK vendor review will catch the gap.

After

You ship the schema migrations, the DSAR endpoint, the retention cron, the logging policy, the DPA register and the breach notification template into the repo this quarter, and the same codebase passes a UK or EU customer's vendor review on first pass.

What happens if you do not address this

The PDPC is in active enforcement mode and UK, EU and Australian customers are increasingly running pre-contract data-handling reviews. A small Sri Lankan engineering shop that cannot show implemented controls loses the export client to a competitor that can.

Who it is for

Working software engineers in Sri Lanka building product or services applications, especially at small to mid-size firms that take on export clients in the UK, EU and Australia, and engineers studying through the SQA route who want a code-first compliance skill that is hard to fake at interview.

Who this is NOT for. Privacy lawyers, DPOs who do not touch the codebase, or compliance consultants who advise but do not implement. The course assumes you can read a schema migration and modify an API handler.

How it arrives

Text-based course in the Art of Service learning environment, plus downloadable templates and worked examples for every module, plus the hand-built implementation playbook delivered alongside course access.

Time investment. Approximately 18 to 22 hours of reading and implementation across four weeks, working alongside a normal engineering workload. Modules are sized so a single evening covers one module plus the code change it asks for.

Why $199 is the right number

Free PDPC guidance covers the Act and the controller obligations but stops at the legal layer. Law firm briefings are priced for enterprise budgets and rarely include the schema, the endpoint code, or the operational runbooks. Generic GDPR engineering courses skip the Sri Lankan controller registration, the PDPC notification timelines, and the GDPR mapping needed for export clients. This course is the only one that walks the actual code changes a working Sri Lankan engineer ships.

FAQ

Is this Act-by-Act commentary on the PDPA?

No. The Act is referenced only where it changes the codebase. The course teaches the implementation, not the legal interpretation.

What stack are the examples in?

The examples target a Python, Node, or Laravel back end with a relational database (PostgreSQL or MySQL), because that covers the majority of small Sri Lankan engineering shops. The patterns translate cleanly to other stacks; the implementation playbook is tailored to whatever stack you actually ship on.

Do I need PDPA legal training to take this?

No. The course assumes you can read a schema migration, write an API handler, and configure a logger. It teaches you what the law requires of the code, not how to be a privacy lawyer.

Will this satisfy a UK or EU customer's GDPR vendor review?

Module 10 and Module 11 map every control implemented to GDPR Articles and produce the attestation pack the procurement reviewer reads. The same codebase that satisfies the PDPA satisfies the bulk of a standard GDPR vendor questionnaire.

What does the implementation playbook contain?

It is hand-built after purchase and contains the schema migrations, the DSAR endpoint scaffold, the retention cron, the logging configuration, the DPA register template, the breach notification template, and the vendor-review attestation pack, tailored to your stack and use case.

30-day money-back guarantee. If after a week of working through the materials this is not what you needed, reply to the receipt email and a full refund is processed. No questions, no forms.

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.