Digital Trust / PDPA for Sri Lankan Enterprises
PDPA Compliance, Built into Your Software Delivery
Bring PDPA requirements into GitLab Ultimate, where your teams already build. Connect project-level controls with the evidence your privacy programme needs, with clear ownership and explicit limits.
Free, open-source framework. GitLab Ultimate subscription required.
People / Technology / Governance
Connect Your Privacy Programme to the Work of Your Teams
Use one framework to connect PDPA requirements, project controls and evidence ownership. Privacy leaders can see what needs support; engineering teams can see the work in their projects; both can distinguish a technical finding from a duty that still needs external evidence.
Privacy & Governance
Connect programme requirements with the projects, records and people responsible for delivery.
Engineering Teams
Review platform findings inside GitLab and identify the controls that need attention.
Software Firms & BPOs
Bring processor responsibilities into the discussion, with project controls and supporting records considered together.
Scope
You are almost certainly in scope, and often not for the reason you expect
Section 2 commences alongside the duties on 1 January 2027, and it reaches four different ways. Any one of them is enough on its own. Read them against your own organisation before you read anything else on this page.
The processing happens here
Any processing of personal data that takes place wholly or partly within Sri Lanka, whoever is doing it and wherever they are registered.
s. 2(1)(a)You are a Sri Lankan organisation
Incorporated or established under Sri Lankan law, or domiciled or ordinarily resident here. Where your customers live does not enter into it. A Colombo software house processing a European client's data is inside the Act.
s. 2(1)(b)(i) and (ii)You sell to people in Sri Lanka
Offering goods or services to data subjects in Sri Lanka, including offerings that specifically target them. This catches foreign platforms as squarely as local ones.
s. 2(1)(b)(iii)You watch behaviour here
Specifically monitoring the behaviour of data subjects in Sri Lanka, including profiling in order to make decisions about that behaviour.
s. 2(1)(b)(iv)Who this was built for
- Banks and finance companies
- Insurers
- Telecommunications
- Hospitals and health groups
- Retail and e-commerce
- Software and product engineering firms
- BPO and shared services
- State institutions and public corporations
If you build or run software for other people, read section 22 first
Sri Lanka's export IT and BPO sector tends to assume the law lands on the client, because the client owns the data. It does not work that way. Section 22 places obligations directly on the processor: process only on the controller's written instructions, bind your personnel to confidentiality and secrecy through appropriate technical and organisational measures, facilitate the controller's compliance audits and inspections on written request, and erase or return data when instructed. Those are your duties, in your name.
A data processing agreement does not discharge them. It only describes them. Section 20 goes further and requires a Data Protection Officer from the processor as well as the controller wherever the core activities meet its tests.
That is precisely why this framework was built inside a software delivery platform instead of a general purpose governance tool. The evidence a processor needs for section 22 lives where the engineers are: in access control, in branch protection, in approval rules, in the audit record of who could reach what and when.
The market gap
Why a PDPA-Specific Framework Matters
NIS 2, as shipped by GitLab
Two requirements for an entire EU directive, mapped to scanner controls.
DORA, as shipped by GitLab
Three requirements, article numbered, again scanner led.
Privacy statute templates
No GDPR template. No privacy statute template of any kind. Nothing for PDPA, and nothing for any comparable law in South Asia.
Those templates are not wrong. They map what a scanner can prove and stop there, which is a defensible house style. It is the wrong style for a privacy statute, because the duties that actually attract a regulator are consent, retention, cross border transfer and breach handling, and a scanner has never seen any of them. A framework that quietly omits those reports on the easy half of the law.
Which leaves a Sri Lankan enterprise choosing between a framework built for a European directive it does not owe, and building its own from the statute. This is the third option.
It takes the opposite line to the shipped templates: every duty becomes a requirement. Where GitLab can attest something, an internal control does it. Where it cannot, an external evidence check does it, and until that check is wired the requirement says so in its own text. Nothing is left out because it is inconvenient to measure.
The clock
Why 1 January 2027 is the date your board should be holding
The Act was certified in 2022 and has been brought into force in pieces ever since, with one enforcement date cancelled four days before it would have bitten. That history has left a lot of Sri Lankan organisations treating the PDPA as permanently forthcoming. It is not. The parts that impose duties on you have an appointed date, and it is fixed by gazette.
It also means that working against "the Act" as a whole is a mistake in the other direction, because it measures duties nobody owes yet. Both frameworks on this page are cut to the commencement position, not to the printed statute.
- 17 Jul 2023The regulator exists. Part V commences, the Data Protection Authority is constituted and its board appointed.
- 1 Dec 2023Machinery follows. The parts covering staff, funding, miscellaneous provisions and interpretation come into force.
- 18 Mar 2025Full enforcement, cancelled. The appointed date is repealed four days before it would have bitten.
- 30 Oct 2025The Amendment lands. Response times, appeal grounds, the officer role and the entire cross border regime are rewritten.
- 1 Jan 2027The duties arrive. The processing obligations and the controller and processor obligations commence. This is what the core framework measures.
- Not setStill unappointed. Data subject rights, direct marketing and the penalty regime have no date. They are tracked in a separate framework so they cannot flatter or spoil today's numbers.
Exposure
What the penalty regime says, and when it actually bites
Two dates, and running them together is the most common error in PDPA planning we see. It is worth being exact, because the honest version of this is more useful to you than the frightening version.
1 January 2027: the duties
Sections 2 and 3, Part I and Part III commence, by Gazette Extraordinary 2498/16 of 22 July 2026. From that date the processing obligations and the controller and processor obligations are law, and the Authority can issue a directive under section 35 requiring you to put something right.
Not yet appointed: the money
Part VII, which carries the penalties, still has no commencement date. When it is appointed, section 38 lets the Authority require payment of a penalty of up to rupees ten million for each non-compliance with a directive, and section 38(2) adds twice that amount again for each subsequent non-compliance after the first.
Why the gap between those two dates does not buy you time
The duties commence first and the penalties follow. An organisation that waits for the penalty date to begin work will be assembling its record of processing activities, its consent evidence and its impact assessments while already in breach, and every record it produces will carry a date later than the duty it is meant to evidence. A directive under section 35 arrives before a penalty under section 38, and it names the period you have to comply in. The useful question is not what the fine is. It is whether you could answer a directive inside thirty days with evidence that predates it.
Because Part VII is unappointed, the penalty provisions are deliberately kept out of the framework you run today. They sit in a second, separate readiness framework, so that a duty nobody owes yet can never move the number for the duties they do. That separation is the whole reason there are two files rather than one.
The map
Schedule Coverage and Supporting Evidence
Expand any item to see how the Amendment changed it, whether it is in force, and which delivery artifact attests it. Filter by coverage to see what a scanner can prove and what needs evidence from outside the platform.
What You Get
A Framework, Project-Level Reporting and a Path to Evidence
Four things come out of this work, and all four are free to download and read. There is no licence to buy from us, no per seat charge and no lock in: the only commercial requirement is a GitLab Ultimate subscription, because compliance frameworks are an Ultimate feature, and that is GitLab's charge rather than ours.
| Artifact | Shape | What it carries |
|---|---|---|
| Core framework built |
49 requirements 47 control instances 45 distinct controls |
Every duty in force from 1 January 2027. The processing obligations one requirement each, the security obligation split across five to carry its 25 controls, the accountability programme broken into its statutory elements, every item of the lawful basis, special category and consent Schedules, the criminal investigation Schedule, the transparency Schedule, and the controller and processor obligations including impact assessments and cross border transfers. |
| Readiness framework built |
11 requirements no controls yet, by design |
The rights, marketing and penalty provisions that have no commencement date. Separate on purpose: a duty nobody owes yet must never move the number for duties they do. |
| Validator blocking CI |
One script, one job | Fails the build on any breach of the platform's own limits, on an unknown control, on an expression that does not match the platform's predefined value, on a committed secret, and on any dash that is not a plain hyphen. It now also checks the framework name, description and colour lengths, and the three part shape of every requirement description. |
| Wiring script service pending |
Dry run by default | Attaches an external evidence check to every requirement that has none, reading its shared secret at run time. It refuses to start without a token and writes nothing until explicitly told to. |
One constraint shaped the whole design
The platform requires a shared secret on every external check, and secrets do not belong in a repository. So the committed framework ships those legal requirements with no control at all, and a separate script attaches them after import using a secret read from a vault. That is deliberate, and it comes with a warning that is worth stating plainly.
A requirement with no control reports nothing
Nothing looks exactly like compliant. Zero controls is a build state, never an operating state. After importing, run the wiring script and confirm that every requirement carries at least one check, otherwise the report is quietly silent about the very duties that matter most.
What changed in this release
- Every requirement description is now laid out in labelled parts, ACT, CONTROL and WHY NOT IN GITLAB, and the build fails if one loses its explanation. The Why not in GitLab tab covers this in full.
- Each framework description now states the position in two sentences: every duty is a requirement, and most carry no GitLab control because the evidence is records rather than configuration.
- Fixed: the readiness framework would not have imported at all. Its description was 316 characters against a GitLab limit of 255, which rejects the whole framework rather than trimming the field. The build now checks name, description and colour lengths, so this class of defect fails the pipeline instead of the import.
- A twenty minute demo plan ships with the repository, with a live track for an Ultimate group and an offline track that needs no licence at all.
Both JSON files on this page are the current release. Their checksums changed with it, so a copy downloaded before this release will not match the sums printed on the Install it tab.
What the first month looks like
This is the realistic shape of a rollout in a mid sized Sri Lankan enterprise, assuming one engineer and one person who owns privacy. It is deliberately unglamorous, because the value arrives in week two and not on day one.
| When | Who | What happens |
|---|---|---|
| Week 1 | Group Owner | Import the core framework into the top level group and apply it to the projects that touch personal data. Roughly an afternoon. Nothing in your pipelines changes and nothing breaks: a framework observes, it does not block. |
| Week 2 | Engineering leads | Read the red. The eleven requirements that carry platform controls will report honestly straight away, and they usually surface real findings: repositories without approval rules, scanners that were switched on once and drifted off, groups without enforced authentication. |
| Week 3 | Privacy owner and engineering | Decide where the evidence for the other thirty eight duties lives: the record of processing activities, the consent register, processor contracts, the transfer instruments. Wire the external evidence checks against those registers. Until this is done those requirements report nothing at all, which is not the same as passing. |
| Week 4 | Data Protection Officer | Take the adherence report to the accountability programme under section 12. You now have a dated, per project record that refreshes itself, rather than a spreadsheet that was true on the morning somebody last updated it. |
Week three is the one that gets skipped, and it is the one that matters most. An unwired requirement is silent, and silence reads exactly like success on a report.
New in this release
Connect Each Requirement to Controls and Evidence Gaps
Requirement descriptions used to be prose, which meant a reader had to work out for themselves which sentence was the duty and which was the attestation. They are now laid out in three labelled parts, in the same order every time, so the Compliance Center can be scanned rather than read.
s. 24 - Personal data protection impact assessments
Before systematic and extensive evaluation, profiling, or monitoring of public areas or telecom networks, the controller must assess the impact first, assisted by the DPO.
A PDPIA register: an entry per triggering activity, DPO involvement, dated before processing, refreshed on change.
The duty attaches to processing activities and to dates preceding processing; no control can see either. An external check is wired after import; until then it reports nothing.
ACT is what the law requires. CONTROL is what attests it, whether that is a GitLab control or a named register held elsewhere. WHY NOT IN GITLAB appears only on the requirements that carry no control, and it always ends by saying that the requirement reports nothing until it is wired.
The build enforces the shape. A description that does not open with ACT, or carries no CONTROL line, or omits WHY NOT IN GITLAB while having no controls, fails the pipeline. A requirement can no longer quietly lose its explanation, which is the failure mode this layout exists to prevent.
The arithmetic
11 Requirements with Platform Controls, 38 Requiring External Evidence
That ratio looks alarming until you see where the 47 checks land. They are not spread thinly across the Act. They are concentrated on the handful of duties that are genuinely about how a platform is configured.
| Requirement | Checks |
|---|---|
| s. 10 integrity and confidentiality, split across five requirements | 25 |
| s. 12(1)(e) merge governance, split across two | 10 |
| s. 12(1)(g) periodic monitoring | 5 |
| s. 12(1)(f) complaints and breach identification | 3 |
| Schedule I item (h) network and information security | 2 |
| s. 25 measures to mitigate risks of harm | 2 |
What GitLab's sixty two controls actually measure
Reading the full control registry makes the pattern obvious. Every one of the 62 is a fact about a project or its pipelines: is a scanner configured, is the default branch protected, are two approvals required, is single sign on enabled, is the project public, are force pushes disabled, is there a valid CI configuration, are CI variables restricted to maintainers.
None of them can express any of the following:
A document exists
A register, a notice, a contract, a policy.
A decision was recorded
And by whom, with the reasoning behind it.
A person was appointed
To a named role, on a date, still holding it.
One date preceded another
Assessed before processing began, not after.
A register is current
Reviewed since the last thing that changed it.
Those are the shapes
Most of the PDPA is written in exactly these five, which is the whole explanation for the 38.
The thirty eight, grouped
| Count | Group |
|---|---|
| 8 | Schedule II items, the special category bases |
| 7 | Part I duties, ss. 4 to 9 and 11: lawfulness, purpose, minimisation, accuracy, retention, transparency |
| 7 | Schedule I items, the lawful bases, all except item (h) |
| 6 | Part III duties: s. 20 officer, s. 21 controller obligations, s. 22 processor obligations, s. 23 breach notification, s. 24 impact assessments, s. 26 cross border transfers |
| 4 | Schedule III items, the consent conditions |
| 3 | s. 12 elements: (a) catalogued records, (b) to (d) design and governance, (h) rights facilitation |
| 2 | Schedule V, the notice duties |
| 1 | Schedule IV, criminal investigations |
All 11 readiness requirements ship with no controls too, for the same reason plus one more: the duties have not commenced.
The whole list
Explore the Requirements
Every requirement in both frameworks, read straight out of the JSON that this page also serves. Expand one to see its three parts and, where it has them, the exact GitLab controls attached and the expression each one evaluates.
An expression reading = false is not a mistake. Three of GitLab's built in controls are inverted, so the compliant answer is false, and the framework has to match the platform's predefined expression exactly or the import is rejected.
The clearest example
Why s. 24 gets no control, in full
Impact assessments are the duty people most expect to see a green tick against, and the one where a green tick would do the most damage. Four reasons rule out a platform control, each sufficient on its own.
Wrong subject
The duty attaches to a processing activity, not to a repository. One project may serve five processing activities, or none at all.
Wrong tense
The duty is to assess before processing begins, so the evidence is that one date preceded another. A scheduled scan reads the present state of a project. It cannot see sequence.
Wrong kind of fact
Whether processing is systematic and extensive is a judgment somebody makes and records. It is not a boolean a scanner can read.
Wrong trigger
A refresh is required when methodology, technology or process changes. GitLab can see that a file changed. It cannot know whether that change altered the processing.
The proxies considered, and rejected
Named here so the decision is reviewable rather than silent.
| Control considered | Why it was rejected |
|---|---|
issue_tracking_enabled | The tempting one, and the worst. A green tick would display against "s. 24 impact assessments" while meaning only that the issue tracker is switched on. |
has_valid_ci_config, status_checks_required | Pipeline hygiene. Unrelated to whether an assessment was carried out. |
error_tracking_enabled | Incident tooling. That is s. 12(1)(f), not s. 24. |
the scanner_* family | Attests that a scanner ran. s. 24 is not about vulnerabilities. |
Each of these would have produced a requirement that passes for reasons having nothing to do with the duty it names.
The contrast with s. 25, which does carry controls
s. 25 sits immediately after s. 24 and carries two internal controls, vulnerabilities_slo_days_over_threshold and package_hunter_no_findings_untriaged. Closing an identified technical risk within a service level is visible to the platform. Deciding whether an assessment was required, and recording that judgment before processing began, is not. The line between those two requirements is where the platform's sight ends.
What the external check asserts instead
A register, queried per project, answering six questions:
- Does a PDPIA register exist.
- Does every processing activity meeting the s. 24(1) triggers have an entry.
- Does each entry record the Data Protection Officer's involvement, s. 24(3).
- Does each entry predate the processing it covers.
- Has each been refreshed after a relevant change, s. 24(4).
- Are entries retrievable on the Authority's written request, s. 24(5).
It returns pass, fail, or could not evaluate, and could not evaluate is never filed as a pass.
A drafting conflict the check must not inherit
The draft PDPIA Regulations, still at version 1.0 from the 2024 consultation, require at regulation 13 that every assessment is delivered to the Authority. The amended s. 24(5) requires submission only on written request.
The evidence service must assert the Act's position and not the stranded draft's, otherwise it will report an organisation as failing a duty that no longer exists. The draft also carries the risk matrix making an assessment mandatory once probability multiplied by impact reaches ten, which is useful and not in conflict.
Why not attach a near enough control
Because of the rule this whole build is held to: a failure must never look like a legitimate answer. A weak mapping does not produce a slightly imprecise report, it produces a confidently wrong one. An auditor reading "s. 24 impact assessments: pass" would reasonably conclude that assessments are being carried out. If that tick actually meant the issue tracker was enabled, the report has not merely failed to help, it has actively misled.
A visible gap can be closed. A false green is not even known about.
What the platform can offer
Research Behind the Framework
Before accepting 38 uncovered requirements as the answer, every GitLab Ultimate capability family was checked against all 60 requirements: 102 agents across five search angles, fifteen sources fetched, every claim put through three vote adversarial verification against GitLab 19.x. Twenty five claims survived into ten findings, none refuted. The one sentence result is that external compliance controls are the only documented path that turns an uncovered requirement into something that can actually pass or fail.
| Finding | What it means for this framework |
|---|---|
| External controls, confirmed end to end 3-0 |
The UI ships the button, GraphQL attaches the control, and the evidence service reports status by PATCH to /compliance_external_controls/:id/status authenticated with HMAC-SHA256 over timestamp, nonce, path and body. That last piece is what the wiring script was missing. |
| The regime is stricter than attest once operational |
With ping enabled, the default since 18.5, GitLab calls the external URL every 12 hours and resets the control to pending. Pending for more than 6 hours fails. The evidence service needs real availability, and its outage reads as compliance failure across every wired requirement. |
| Controls are evaluated per project decision |
An organisation level fact, such as the appointment of one Data Protection Officer, is attested once per project. The framework stays applied to the real projects that process personal data, and the service answers organisation level questions identically for each. A single synthetic evidence project would make the report describe a project that processes nothing. |
| The five control cap counts both kinds headroom |
The eight requirements already at 5 of 5 need no external control, so the cap costs nothing today. It does mean s. 12(1)(f) can take at most two external checks, and Schedule I (h) and s. 25 at most three each. |
| Where results surface, and where they do not the gap |
The compliance status report shows adherence per control per project, so the 47 internal instances produce rows today and the 38 uncovered requirements produce no rows at all. The violations report detects exactly four controls, all merge request separation of duties, so its only honest scope here is s. 12(1)(e). |
| Audit events are supporting evidence, never attestation supporting |
Streaming delivers every audit event for a top level group as structured JSON. That attests GitLab configuration history, not the controller's processing of personal data. It supports s. 10 access management, s. 12(1)(a) record keeping and s. 23 breach forensics. Immutability has to come from the destination, for example S3 Object Lock. |
| Centralized distribution is not available ruled out |
Centralized compliance frameworks through a CSP group are Self-Managed and Dedicated only, not GitLab.com. So the framework is distributed by importing the JSON per top level group, exactly as the install steps describe. |
What produced no verified claims, said plainly
The research fanned out across every capability family requested. These returned no surviving verified claims and remain honestly unmapped rather than quietly assumed: scan execution, scan result and pipeline execution policies, merge request approval policies as a separate mechanism, protected environments and deployment approvals, vulnerability management and SBOM, custom member roles, service accounts, credentials inventory, IP allowlists and SAML SSO enforcement, the standards adherence CSV export, GitLab Duo AI governance, retention and housekeeping settings, and webhook automation.
Absence of a verified claim is not proof of absence. Custom roles against s. 12 governance, credentials inventory against s. 10, and the CSV export as regulator facing evidence are all candidates for a second pass. Until then they stay off the framework, because an unverified mapping is exactly the kind of comfortable green this build refuses.
The long forms of both arguments live in the repository, as docs/WHY-NO-CONTROLS.md and docs/CAPABILITY-ANALYSIS.md, with the verified research result and its votes alongside them. If you disagree with a mapping, that is where to aim.
Get the files
Download the Core and Readiness Frameworks
Nothing here is compiled or generated. Open either file in a text editor and you can read the requirements as English sentences, change a word, and import it again.
Every duty that becomes binding on 1 January 2027, including each item of the Schedules. This is the one to start with.
Changed in this release
- All 49 requirement descriptions rewritten into the labelled ACT, CONTROL and WHY NOT IN GITLAB parts. The 38 that carry no control now state why in their own text, so the reason travels with the requirement into the Compliance Center.
- Framework description rewritten, 222 to 254 characters, so the summary a compliance officer sees first says that every duty is a requirement and that most carry no GitLab control.
- Unchanged: 49 requirements, 47 internal control instances, and every control set. No mapping was added, removed or altered, so adherence numbers do not move on reimport.
Built from 5dd3174, 3 September 2026. Release note.
The rights, marketing and penalty duties that have no start date yet. Import this only if you want to track them separately, which is the point of it.
Changed in this release
- Fixed: the previous file would not have imported at all. Its framework description was 316 characters against a GitLab limit of 255, and GitLab rejects the whole framework rather than trimming the field. It is now 241 characters. If you hold an older copy, this is the one change that matters.
- All 11 requirement descriptions rewritten into the same labelled ACT, CONTROL and WHY NOT IN GITLAB parts as the core file.
- Unchanged: 11 requirements, and still no controls at all. That is deliberate and stays true until these duties are given a commencement date.
Built from 5dd3174, 3 September 2026. Release note.
The checksums are worth a moment. If the one you compute locally does not match the one printed here, you have a different file from the one this guide describes, and importing it will not give you what is written above.
On versions, plainly
There is no tagged release yet. The repository keeps a release note that every merge request appends to, and everything shipped so far still sits under its Unreleased heading, so the honest version identifier for both files is the commit they were built from, 5dd3174 of 3 September 2026. Both files on this page are that commit.
The upstream project cuts a release by promoting Unreleased to a version heading and tagging it. Until that happens, check the note and the checksum rather than a version number.
Read the full release note · see the commit · the frameworks README
Install it
Install the Framework and Connect Your Projects
Before either route, three things have to be true, and it is worth checking them before you book anyone's time. You need GitLab Ultimate, because requirements and controls are an Ultimate feature. You need to be an Owner of the group, or to hold the Security Manager role. And it has to be a top level group, because a framework lives on a group: a project sitting in a personal namespace cannot hold one, which catches people out.
Importing changes nothing about how your teams work. A compliance framework observes projects and reports on them. It does not block a pipeline, gate a merge or alter a setting, so there is no rollback plan to write and no maintenance window to book.
By hand, in the browser
This is the route GitLab supports and documents. If you are doing this once, do it this way.
- Download pdpa-sl-core.json from the cards above.
- Open your group and go to Secure, then Compliance center, in the left sidebar.
- Select the Frameworks tab.
- Select New framework, then Import framework.
- Choose the JSON file. GitLab reports any requirement it could not create, so read that message rather than closing it.
- Open the Projects tab and apply the framework to the projects it should cover.
- Wire the external evidence checks, otherwise the legal requirements carry no control and quietly report nothing at all.
From a terminal
Fetching and checking are ordinary shell work. The import step at the end is the experimental part, and it is labelled below.
# 1. get the file curl -O https://mcps.work/frameworks/pdpa-sl-core.json # 2. check it arrived intact sha256sum pdpa-sl-core.json # expect 1ccf68f6...731a # 3. read what you are about to import python3 -c "import json;d=json.load(open('pdpa-sl-core.json'));\ print(d['name'], len(d['requirements']), 'requirements')"
Then either import it in the browser using the steps on the left, or try the API route:
# a token with the api scope, no default, never committed export GITLAB_TOKEN=glpat-your-token # shows what it would do, writes nothing python3 import_framework.py \ --group your-top-level-group \ --file pdpa-sl-core.json # add --apply when the dry run looks right
About that API route
GitLab documents the browser import, not an import API. The script calls GraphQL mutations whose names were read out of the GitLab source rather than confirmed against a live schema, and it has not yet been run against a real Ultimate group. It refuses to write without --apply, and if a field name is wrong it prints the server's own error rather than hiding it. Treat it as a head start, not a guarantee, and use the browser route if you want the supported path.
Coverage Has Boundaries
Understand the Limits of a Green Report
This list ships with the framework and is maintained as deliberately as the requirements themselves, because the day a green tick is trusted beyond its evidence is the day it becomes worse than having no tick at all. If you are evaluating this against a commercial compliance product, evaluate that product against this list too, and ask where its equivalent is published.
- It does not prove processing is lawful. Internal controls attest platform configuration. External checks attest that a register exists and is current. Neither attests that the legal judgment written in that register is correct. That judgment stays human.
- It does not prove readiness for the rights regime. Those provisions have no commencement date and live in the second framework on purpose.
- It does not prove findings were triaged. A scanner control attests that the scanner ran, nothing more.
- It does not cover the regulator's own machinery. That Schedule governs the Authority and imposes no duty on a controller.
- It says nothing at all about a requirement with no control. Silence and success look identical in a report. Only the wiring run closes that gap.
How it was verified
Three Working Rules
A failure must never look like a legitimate answer
Zero is a valid result, so zero can never be the failure signal. The validator exits with one code when a file is invalid and a different code when it could not evaluate at all, and could not evaluate is treated as its own verdict rather than being quietly folded into a pass.
A passing test is not evidence until you have watched it fail
Four faults were seeded on purpose: an unknown control, an expression that did not match the platform's predefined value, a forbidden dash, and a committed secret. Each produced a message naming that specific fault. The check was then re-run after its own error text was edited, because a control you have changed has not been proven to still fire.
Read the source, not the documentation, when the limit matters
Every server side limit came from the platform's own code rather than from prose: the ceiling on requirements per framework, the ceiling on controls per requirement, the length limits, and the exact expression for all sixty two built in controls. That last one mattered more than expected, because six of them are not the simple boolean they appear to be, and three are inverted, where the compliant value is false.
Provenance
Sources
Built from the Act and its 2025 Amendment, the commencement gazettes, the regulator's public circulars and its draft rules, regulations and directives, all published by the Data Protection Authority of Sri Lanka. Where a draft instrument now conflicts with the amended Act, the conflict is recorded rather than smoothed over.
GitLab is a trademark of GitLab B.V. The GitLab logo appears here only to identify the product this guide is about, and its use does not imply any endorsement. This is an independent field guide. It is not legal advice, and it is not affiliated with or endorsed by the Data Protection Authority of Sri Lanka or by GitLab. Where the Act's language differs between its official texts, the Sinhala text prevails.
Open source
An Open Framework for Digital Trust in Sri Lanka
This framework is a work in progress and it is public. All of it, both JSON files, the validator, the wiring script and this write up, lives in an open GitLab repository under an open licence. Take it, fork it, run it inside your own organisation, change what does not fit. There is nothing to sign and nobody to ask.
That is a deliberate choice rather than a marketing posture. A compliance artifact that you cannot read is a compliance artifact you cannot check, and a Sri Lankan enterprise should not have to take a foreign vendor's word for what its own statute requires. If the mapping of section 24 is wrong, you should be able to see that it is wrong.
If you work in privacy, compliance or GitLab administration, a careful eye on it is worth a great deal. Good ways to get involved:
- Read a requirement against the Act and tell us where the mapping is wrong.
- Run the import against a real Ultimate group and report what the platform actually does.
- Propose an external evidence check for a requirement that carries no control.
- Tell us what your sector needs. A bank, a hospital and a BPO read the same Act very differently.
- Open an issue, or a merge request, for anything from a typo to a whole Schedule.
Visit the repository on GitLab
Contributions are read against the source, not the documentation. The same three working rules apply to anything that lands.
Bring the Framework into Your Environment
Discuss the projects in scope, the people who own your evidence and the checks that need to be connected. The framework is free to evaluate independently; implementation support starts with understanding your environment.