The Law That Exists But Doesn’t — Sri Lanka’s PDPA Implementation Paradox

Here is a timeline. Read it carefully.

November 2021. The Personal Data Protection Bill is presented to Parliament. It has been years in the making, driven primarily by Sri Lanka’s ambitions for EU adequacy status and the requirements of the country’s growing IT and BPO export sector.

March 2022. The Act is certified. Sri Lanka becomes the first South Asian country with comprehensive data protection legislation. Press releases are issued. Conferences are organised. PowerPoint decks are prepared.

April 2022. Sri Lanka defaults on its sovereign debt for the first time in its history. The economic crisis consumes everything. Data protection becomes, understandably, nobody’s priority.

July 2022. The President flees the country. The political system convulses. An IMF programme becomes the overriding focus of government policy.

2023. The Data Protection Authority is quietly established. A Board is constituted. But no commencement dates are announced for the substantive provisions — Parts II through VI.

2024. The Authority begins work. The Sri Lanka Institute of Development Administration (SLIDA) starts running awareness sessions. Industry bodies begin asking questions. Still no commencement dates.

October 2025. The Amendment Act is certified, modifying thirteen sections of the original PDPA. The commencement mechanism is changed to allow different provisions to come into force on different dates. Still no specific dates announced.

March 2026. You are here. The Act is four years old. The Authority exists. The Amendment has been passed. And the core obligations — the ones that actually require businesses to change what they do — have not commenced.

This is the PDPA implementation paradox: a comprehensive data protection law that is simultaneously real and not real, enacted and not enforced, binding in theory and optional in practice.

The Anatomy of a Delay

To understand why we are where we are, you need to understand the original commencement structure and how it was changed.

The original PDPA divided itself into seven Parts. Part I (Preliminary — definitions and scope) and Part VII (the Data Protection Authority — establishment, powers, Board composition) came into force immediately upon certification in March 2022. This was deliberate: you need the institution to exist before it can enforce the rules.

Parts II through VI — which contain everything that actually matters to businesses: the processing principles, the data subject rights, the direct marketing restrictions, the cross-border transfer rules, the enforcement and penalty provisions — were to come into force “on such date as the Minister may appoint by Order published in the Gazette.”

The original expectation was a transition period of about two years. By early 2024, the thinking went, the Authority would be operational, guidance would have been issued, and the substantive provisions would commence.

That did not happen. And the reasons are multiple.

The economic crisis. Between 2022 and 2024, Sri Lanka was in genuine economic distress. Inflation peaked above 50%. GDP contracted. The IMF programme imposed strict fiscal discipline. Government bandwidth for anything that was not directly crisis-related was essentially zero. Data protection regulation was a luxury the state apparatus could not afford to focus on.

Institutional capacity. The Data Protection Authority was established, but building a functioning regulatory body takes time, especially in a country with no prior history of data protection regulation. Staff needed to be hired and trained. Processes needed to be developed. Guidance needed to be drafted. None of this happens overnight.

Industry readiness. The honest truth is that Sri Lankan businesses — with a few notable exceptions — were nowhere near ready for PDPA compliance when the Act was certified. Many are still not ready. Commencing the substantive provisions without giving industry adequate time to prepare would have been punitive rather than productive.

The Amendment. By 2024, it had become clear that certain provisions of the original Act needed modification. The cross-border transfer restrictions were too strict for the IT/BPO sector. The commencement mechanism was too rigid. Some definitions needed clarification. The government chose to amend first and commence later, which is pragmatic but adds further delay.

The 2025 Amendment replaced the original single commencement trigger with a more flexible mechanism. Section 1 of the Amendment provides that different provisions can be brought into operation on different dates. This means the Authority can, for example, commence the processing principles first, the data subject rights second, and the penalty provisions third, giving industry time to adjust to each layer of obligation.

This is good regulatory design. It is also a recipe for extended uncertainty.

Why This Matters More Than You Think

You might be reading this and thinking: if the law hasn’t commenced, why should I care? Why prepare for something that might not happen for another year?

This is a natural reaction. It is also a trap.

Behavioural economists have a concept called the fresh start effect. People are more likely to pursue goals after temporal landmarks — New Year’s Day, birthdays, the start of a new quarter. The flip side of this is that in the absence of a clear temporal marker, people defer. Indefinitely.

The PDPA’s uncommenced state has created a massive organisational fresh start problem. Without a hard commencement date, there is no urgency. Without urgency, there is no budget. Without budget, there is no preparation. And without preparation, when the commencement date is finally announced, there will be panic.

This is not theoretical. We have seen this pattern play out in every jurisdiction that has enacted data protection legislation. The GDPR gave organisations a two-year transition period from adoption to enforcement. Despite this generous timeline, surveys consistently showed that a significant proportion of organisations were not ready when the deadline arrived in May 2018. Some are still not fully compliant years later.

Sri Lanka’s situation is worse. The GDPR at least had a fixed date. Organisations could count down. They could plan backwards from a deadline. The PDPA’s floating commencement creates a different psychology entirely — one of perpetual deferral.

There is another behavioural economics concept at work here: present bias. Humans systematically overvalue present benefits and undervalue future costs. The cost of PDPA compliance is real and immediate — it requires time, money, and organisational change. The benefit of compliance is future and uncertain — avoidance of penalties that may or may not be enforced, reduction of risks that may or may not materialise.

In a rational world, organisations would begin preparing now, spreading the cost over time and avoiding the need for a panicked crash programme later. In the real world, present bias means that most organisations will wait until the last possible moment, and then spend more to achieve less in less time.

The Institutional Readiness Problem

Let’s be fair to the Authority. Building a data protection regulator from scratch is genuinely hard, and Sri Lanka faces challenges that other jurisdictions did not.

The talent pool is thin. Data protection is a specialised discipline that sits at the intersection of law, technology, and public policy. There are very few people in Sri Lanka with deep expertise in all three areas. The Authority needs to staff itself with people who understand both the legal framework and the technical realities of data processing. These people are scarce globally; in Sri Lanka, they are nearly nonexistent.

There is no regulatory precedent. Sri Lanka has no prior history of sector-agnostic data protection regulation. The Central Bank regulates financial data. The Telecommunications Regulatory Commission has some authority over telecoms data. But a general-purpose data protection regulator is entirely new. There are no institutional templates, no established practices, no regulatory muscle memory.

Rajeeva Bandaranaike’s challenge. The DPA Chairman has inherited an enormous mandate with limited resources. The Authority must simultaneously develop its own internal capabilities, draft guidance for industry, build enforcement capacity, and manage the expectations of a business community that ranges from “what is the PDPA?” to “when exactly do we need to be compliant?” This is a sequencing problem of considerable complexity.

The SLIDA sessions — awareness programmes run by the Sri Lanka Institute of Development Administration in conjunction with the Authority — are a positive sign. They indicate that the Authority is actively working to prepare both the public and private sectors. But awareness is the first step, not the last. The gap between “knowing about the PDPA” and “being compliant with the PDPA” is vast.

There is also a sequencing problem. The Authority needs to issue guidance before it can reasonably expect compliance. But it needs resources and expertise to issue guidance. And it needs the law to be commenced (or at least imminent) to create the urgency that drives resource allocation. It is a chicken-and-egg problem that can only be broken by a deliberate act of political will.

The Parallel Regulatory Universe

Here is something that many PDPA commentaries miss: even without the PDPA’s substantive provisions being in force, Sri Lankan businesses are not operating in a data protection vacuum. There is a parallel regulatory universe that already imposes data-related obligations, and it is growing.

The CBSL Direction on Financial Consumer Protection Relations (FCPR). The Central Bank’s Direction on managing financial consumer protection relations includes data protection provisions that apply to licensed banks and finance companies. These are already in force. If you are in financial services, you already have data protection obligations — they just don’t come from the PDPA.

Consumer Affairs Authority Direction No. 91. This Direction includes provisions on consumer data handling that apply to certain categories of businesses. It is less comprehensive than the PDPA, but it exists and it is enforceable.

The Computer Crimes Act No. 24 of 2007. This Act criminalises unauthorised access to computers and data. While it is not a data protection law per se, it creates criminal liability for certain types of data mishandling. If someone hacks your systems because you failed to implement basic security, the Computer Crimes Act may be relevant — just not in the way you’d like.

The Telecommunications Act. The TRC has authority over the handling of subscriber data by telecommunications operators. This includes provisions on data retention, interception, and disclosure that predate the PDPA.

The Banking Act. Banking secrecy provisions in the Banking Act create obligations around customer data that are, in some respects, more stringent than the PDPA’s requirements. The relationship between banking secrecy and data protection is complex and will be examined in detail in Part 5.

The Right to Information Act No. 12 of 2016. The RTI Act creates a right to access information held by public authorities. This intersects with data protection in complex ways — the right to information can sometimes conflict with the right to data protection, and the PDPA does not clearly resolve all of these conflicts.

The point is this: the PDPA does not arrive in a regulatory vacuum. It arrives in a cluttered, overlapping, sometimes contradictory regulatory landscape. Understanding how the PDPA interacts with existing regulation is essential for any compliance programme. We will map this in detail in Part 5.

What Should You Be Doing Right Now?

Given the current state of play — Act enacted, Amendment passed, substantive provisions uncommenced — what should a prudent organisation be doing?

The answer depends on your size and sector, but there are some universal steps.

For large enterprises and regulated entities

Appoint a project lead. Someone needs to own PDPA readiness. This does not have to be a Data Protection Officer (that comes later, when the relevant provisions commence), but it needs to be someone with sufficient authority and bandwidth to drive cross-functional change. In practice, this often sits with the Chief Information Security Officer, the Head of Legal, or the Chief Risk Officer. Wherever it sits, it needs board-level visibility.

Conduct a data inventory. You cannot comply with the PDPA if you do not know what personal data you hold, where it is, how it got there, who has access, and what you do with it. A data inventory — sometimes called a data mapping exercise — is the foundation of any compliance programme. Start this now. It takes longer than you think.

Review your legal bases. For each category of personal data you process, identify your legal basis under the PDPA. Consent? Contractual necessity? Legitimate interest? If you cannot identify a clear legal basis for a processing activity, that processing activity has a problem.

Assess your cross-border flows. If you transfer personal data outside Sri Lanka — to a cloud provider, to a parent company, to a BPO partner — you need to understand the post-Amendment cross-border transfer framework. The good news is that the Amendment significantly liberalised this area. The detail is in Part 6.

Budget for compliance. PDPA compliance is not free. It requires investment in technology (consent management, data subject request handling, data discovery and classification tools), people (training, possible DPO hire or outsourcing), and process (policy development, impact assessments, vendor management). Get this into your budget cycle now, because budget cycles are annual and you may not get another chance before commencement.

For SMEs and startups

Understand the scope. The PDPA applies to you. There is no small business exemption. If you process personal data — and you do, because every business does — you are within scope. The scale of your obligations may be proportionate to the scale of your processing, but the obligations exist.

Clean up your data practices. Stop collecting data you don’t need. Delete data you no longer use. Secure the data you have. These are good practices regardless of the PDPA, and they will form the foundation of your compliance effort.

Review your third-party relationships. If you use a CRM, an email marketing platform, a payment processor, a cloud hosting provider — you need to understand what those providers do with the data you share with them. Under the PDPA, you are responsible for ensuring that your processors comply with the Act. Start asking questions of your vendors now.

Watch for guidance. The Authority will issue guidance and regulations as commencement approaches. When this guidance appears, read it. It will tell you what the Authority considers important, how it interprets ambiguous provisions, and where it is likely to focus enforcement attention.

For technology companies and IT/BPO operators

Understand that you are likely both a controller and a processor. You process your own employees’ data (controller). You process your clients’ customers’ data (processor). These are different roles with different obligations under the PDPA, and you need to be compliant in both.

Review your client contracts. The PDPA imposes specific requirements on the relationship between controllers and processors. Your existing service agreements may not address data protection adequately. Start reviewing and updating them now, particularly if you serve international clients who may already be subject to GDPR or other data protection regimes.

Build privacy into your products. If you are building software for the Sri Lankan market, building data protection compliance into the architecture from the start is dramatically cheaper than retrofitting it later. This is not just good engineering practice; it is a competitive advantage. Clients will increasingly ask about PDPA compliance, and being able to demonstrate it will win you business.

The Optimistic Reading

It would be easy to read this and feel pessimistic. The law is delayed. The Authority is under-resourced. Industry is unprepared. The regulatory landscape is fragmented. Everything is uncertain.

But there is an optimistic reading, and it is important.

The delay is an opportunity. Organisations that start preparing now — while the substantive provisions are uncommenced, while the Authority is still building its enforcement capacity, while competitors are still in denial — have a window of opportunity that will not remain open indefinitely. The early movers will be better prepared, will spend less (because they can spread costs over time), and will be better positioned when commencement arrives.

The Amendment was well-designed. The 2025 Amendment addressed many of the most significant concerns about the original Act. The cross-border transfer liberalisation was essential for the IT sector. The flexible commencement mechanism is pragmatic. The extended response timelines are realistic. The Authority has shown that it can identify and fix problems.

International alignment is valuable. Sri Lanka’s PDPA is broadly aligned with the GDPR and other international data protection standards. This means that compliance with the PDPA will make it easier to do business with jurisdictions that require data protection as a condition of trade. For the IT/BPO sector especially, PDPA compliance is not just a cost — it is a market access enabler.

Better data practices have intrinsic value. Data minimisation, purpose limitation, accuracy, security — these are not just legal obligations. They are good engineering principles. Organisations that practice them will have cleaner data, more efficient systems, fewer breaches, and greater customer trust. The PDPA is a forcing function for practices that make organisations better, regardless of regulatory compliance.

The clock is ticking, even if nobody has set the alarm.