What actually changed in April 2026
Bangladesh's data protection framework has been a moving target since 2025. The Personal Data Protection Ordinance, 2025 first set out the interim rules, then the Personal Data Protection (Amendment) Ordinance, 2026 (Ordinance No. 23 of 2026) revised several provisions before Parliament finally passed the permanent Personal Data Protection Act, 2026 (Act No. 63 of 2026) in April, putting the framework on stable statutory footing rather than executive ordinance. For a consultant advising clients through this period, the practical lesson is that the direction of travel has been consistent even while the specific text kept shifting: broader extraterritorial reach, a narrow but strict data residency carve-out for sensitive categories, and a gradual softening of the criminal liability that spooked company boards when the original Ordinance was drafted.
If you advised a client under the 2025 Ordinance and haven't revisited that advice since, it is worth doing so now. The Amendment Ordinance changed the penalty structure in a way that materially affects board-level risk appetite (more on that below), and the final Act's text is what regulators and courts will actually apply going forward, not the interim ordinance language.
Who the Act applies to
The Act's scope is broader than most Bangladesh business owners initially assume, and this is the first place I redirect a client's attention when this topic comes up. It is not limited to companies physically operating inside Bangladesh. The Act has extraterritorial application: it reaches processing activity carried out outside Bangladesh when that processing is connected to providing products or services to data subjects located in Bangladesh, or to monitoring the behaviour or managing records of Bangladesh-resident data subjects. This mirrors the extraterritorial design of the EU's GDPR and, closer to home, India's DPDP Act.
Two groups should read this carefully. First, Bangladesh companies with a subsidiary, distributor, or SaaS product processing data on customers based abroad, since the reverse logic can trigger foreign privacy law exposure on top of the domestic Act. Second, and more relevant to most Odoo implementations I see, any foreign entity (a parent company's regional ERP instance, a foreign-hosted eCommerce platform, an offshore call centre operator) that processes personal data belonging to people located in Bangladesh, even if that entity has no registered office here. If a Bangladesh subsidiary's customer or HR data flows up into a group-wide ERP hosted and controlled from a foreign head office, that arrangement is now squarely inside the Act's scope, and the question of whose obligation it is to ensure compliance (the local entity, the foreign parent, or both) needs to be resolved contractually, not left ambiguous.
The compliance mechanisms it introduces
Strip away the extraterritorial scope question and the Act's substantive obligations will look familiar to anyone who has implemented GDPR-adjacent compliance elsewhere: a lawful basis requirement for processing, consent management obligations, mandatory privacy notices, defined data subject rights (access, correction, and in some form, erasure), breach notification duties, security safeguard requirements, data retention controls, specific protection for children's data, a mandatory Chief Data Officer role for applicable organisations, and governance requirements for cross-border data transfers.
Lawful basis & consent
Processing personal data needs a defined legal basis; where consent is the basis, it must be genuinely informed and revocable, not buried in a generic terms-of-service checkbox.
Privacy notices & DSR
Data subjects must be told what is collected and why, and given a functioning channel to request access, correction, or deletion of their data.
Breach notification
A defined obligation to notify on discovering a personal data breach, which means an organisation needs to actually be capable of detecting one in the first place.
Retention controls
Personal data cannot be retained indefinitely by default; retention periods need a stated rationale tied to business or legal need.
None of these obligations are exotic to an experienced ERP consultant, and none of them require ripping out Odoo. What they require is deliberate configuration: access rights scoped by role rather than left wide open, a documented retention policy that someone actually enforces (Odoo does not delete old records on its own), and an internal owner (the Chief Data Officer, discussed further below) who can answer a data subject access request without a scramble through several modules and a spreadsheet.
The baseline obligations touch nearly every business. The residency rule touches almost none of them. Most of the anxiety I hear from clients is aimed at the wrong half of the law.
Restricted data and Critical Information Infrastructure
This is where the Act gets genuinely strict, and where it deliberately overlaps with a separate law. The data residency rule (covered in detail in the next section) is triggered by two categories: data classified as "restricted data," and data processed by an organisation that qualifies as Critical Information Infrastructure (CII) under the Cyber Security Ordinance, 2025.
I have written a companion piece specifically on the Cyber Security Ordinance and its CII designation, Cyber Security Ordinance 2025 & ERP Hosting Bangladesh, because the honest answer to "what is CII" is more complicated than either law states plainly. The Cyber Security Ordinance names sectors, power, energy, healthcare, banking, communication systems, and government data systems, as nationally critical, but it does not give a fixed, closed-form definition inside its own text. It delegates the specific inclusion criteria to government guidelines that are issued and updated separately from the Ordinance itself. That means a business cannot fully resolve its CII status by reading the two laws alone; it needs to check the current guidelines, which is a genuinely awkward compliance posture for something with this much consequence attached, and one I think practitioners should be candid about rather than paper over with false confidence.
"Restricted data" as a standalone category is somewhat easier to reason about even without a single itemised list, because it clearly tracks the kind of information that would cause real harm if mishandled: sensitive personal categories (health, biometric, financial account detail at scale, national identity data), and by extension the data flowing through the CII sectors named above. A general trading company's Odoo instance, holding supplier contacts, sales orders, and payroll, does not obviously fall into this category. A bank's core systems, a hospital group's patient records platform, or a telecom operator's subscriber database clearly does.
Note: Neither the Personal Data Protection Act's "restricted data" category nor the Cyber Security Ordinance's CII definition is a closed, self-contained list you can check against and be done. Both depend partly on classification decisions and guidelines issued outside the primary legislative text. Treat any confident-sounding blanket statement, including from this article, as a starting point for a proper legal determination specific to your business, not a substitute for one.
The data residency rule, precisely
Here is the operative rule as I read it: where data is categorised as restricted data, or is processed by an organisation operating Critical Information Infrastructure, at least one synchronised, real-time copy of that data stored in the cloud must be maintained within Bangladesh's borders. Read that carefully, because the wording matters for how you architect around it. It does not say the primary system must be hosted in Bangladesh. It does not prohibit foreign cloud hosting outright. It requires a synchronised, real-time in-country copy to exist alongside whatever primary hosting arrangement a qualifying organisation runs.
For an organisation that does fall into scope, this has concrete infrastructure implications. A synchronised, real-time copy is a materially stronger requirement than a nightly backup exported to a Bangladesh-based storage bucket; "real-time" implies something closer to a live replica or a near-continuous replication stream, not a batch job that runs once a day. For an Odoo deployment, this pushes toward architectures like a primary Odoo.sh or foreign-hosted instance replicating its PostgreSQL database continuously to a Bangladesh-hosted standby (via logical replication or a comparable mechanism), plus attachment/filestore synchronisation, which is a nontrivial infrastructure project, not a checkbox in Odoo's settings menu.
Determining whether your Odoo data is restricted
Given the ambiguity described above, I walk clients through a structured self-assessment rather than a yes/no gut call, and I recommend documenting the answer even when it comes out negative, because a written determination with dated reasoning is worth far more in front of a regulator than an undocumented assumption. The questions I actually ask:
- Does the business operate in, or provide outsourced systems for, banking, power, energy, healthcare, telecom, or government data systems?
- Does the Odoo instance store health records, biometric identifiers, or national ID data at a scale beyond routine employee HR records?
- Does the business process payment card data or bulk financial account data on behalf of third parties, rather than just its own transactions?
- Has the business received, or would it reasonably expect to receive, a formal government designation as CII under current guidelines?
- If none of the above apply, is there a documented, dated note in the compliance file recording that determination and the reasoning?
For the overwhelming majority of the manufacturing, trading, and RMG-adjacent clients I work with, the honest answer to the first four questions is no, and the residency rule simply does not bind their Odoo hosting decision. But "probably no" said informally in a meeting is a different risk posture than a dated, documented "no" with the reasoning attached, and the second one is what I actually deliver as part of a hosting engagement now.
Odoo.sh, self-hosted in Bangladesh, and self-hosted abroad
Assuming a business has determined it is not processing restricted data and is not CII (the common case), the choice between hosting models reverts to the ordinary trade-offs I cover in On-Premise vs Cloud Odoo Bangladesh: reliability, cost of ownership, internet infrastructure at the client site, and IT staffing. Odoo.sh, hosted by default in the EU (typically France or Belgium depending on the plan and region selected), remains a perfectly compliant choice for these businesses, provided the Act's general obligations (consent, privacy notices, breach response capability, retention discipline) are configured on top of it, since Odoo.sh itself does not automatically make a client's implementation compliant with any jurisdiction's privacy law.
| Hosting model | Where data lives | Residency rule impact if NOT restricted/CII | Residency rule impact if restricted/CII |
|---|---|---|---|
| Odoo.sh (EU default) | EU data centre | No additional requirement; general obligations still apply | Must add a synchronised real-time in-country copy; primary hosting can remain EU-based |
| Self-hosted in Bangladesh | Local data centre or on-premise server | Residency rule is moot; already satisfied by default | Already satisfied; simplest compliance posture for qualifying businesses |
| Self-hosted abroad (AWS/DigitalOcean foreign region) | Foreign cloud region chosen at setup | No additional requirement; general obligations still apply | Must add a synchronised real-time in-country copy; same architecture burden as Odoo.sh case |
For a business that has genuinely determined it is not restricted-data or CII scoped, I do not recommend proactively building a Bangladesh replica "just in case." The Act does not require it, the infrastructure and licensing cost of real-time database replication is not trivial, and over-engineering compliance for a risk that has been assessed and ruled out wastes budget better spent on backup discipline (see Odoo Backup, Restore & Disaster Recovery Bangladesh) and general security hardening, which matters regardless of this specific law.
The Chief Data Officer requirement in practice
The Act's mandatory Chief Data Officer role, applicable to organisations meeting whatever threshold the implementing rules eventually specify in detail (typically tied to data volume or sector, echoing how similar roles are scoped under GDPR-style laws elsewhere), is not a requirement to hire a new C-suite executive for most SMEs. In every mid-size Bangladesh company I have advised on this, the workable approach is formally designating an existing senior person, commonly whoever already owns IT, legal, or finance, as the named Chief Data Officer, with a written mandate and real authority attached to the title rather than a nominal label.
What actually matters for that person's effectiveness with an Odoo-based operation is access and visibility, not job title. They need to be able to answer, without a week of investigation: what personal data does our Odoo instance hold, who inside the company can see it, what happens to it when an employee or customer relationship ends, and how would we respond if someone submitted an access or deletion request tomorrow. In practice, this means the Chief Data Officer should have direct familiarity with Odoo's Settings > Users & Companies > Users access rights configuration, the retention posture of key models (Contacts, HR Employee records, CRM Leads), and a documented process, even a simple one, for handling data subject requests rather than improvising when the first one arrives.
Penalties and enforcement after the Amendment Ordinance
The most consequential change between the original 2025 Ordinance framework and today's Act, from a board-level risk perspective, is the removal of criminal imprisonment exposure for a managing director tied to data-subject-rights violations. The Personal Data Protection (Amendment) Ordinance, 2026 amended Section 48 to replace that imprisonment provision with monetary fines only. This meaningfully de-escalated the personal risk that had made some Bangladesh company directors treat the original Ordinance as an existential threat rather than a compliance program to plan for calmly.
That said, monetary fines under the permanent Act should not be treated as trivial cost-of-doing-business line items, particularly for repeated, wilful, or large-scale violations, where enforcement bodies in comparable jurisdictions have shown a pattern of escalating penalty severity for organisations that ignore earlier warnings. The right posture for a client is neither panic about imprisonment (that risk has been legislated away for this category of violation) nor complacency about fines (which remain a real and potentially significant cost).
A practical pre-audit checklist for an Odoo-running business
- Document a dated restricted-data / CII self-assessment, even if the answer is no.
- Designate a Chief Data Officer (existing staff member) with written mandate.
- Review Odoo user access rights against actual job need, not historical convenience.
- Draft or update the privacy notice covering what Odoo-stored data is collected and why.
- Define a retention policy per major model (Contacts, Employees, CRM) and a process to enforce it.
- Confirm hosting provider and region, and re-run the residency rule logic if it changes.
- Establish a breach detection and notification procedure, tested at least once.
Where this is heading
Bangladesh's data protection regime is still young enough that enforcement patterns, and the granularity of the CII and restricted-data guidelines, will keep evolving for the next few years. My expectation, based on how comparable laws matured in India and across ASEAN, is that enforcement in the early period will concentrate on visible, large-scale violations (major breaches, egregious non-compliance by CII-designated entities) rather than aggressive scrutiny of ordinary SME Odoo deployments handling routine business data. That is not a reason to skip the self-assessment described above; it is a reason to do the assessment calmly, document it properly, and move on to running the business, rather than either ignoring the law or over-investing in compliance infrastructure the business does not actually need.
If you run Odoo for a Bangladesh business and want a clear-eyed determination of whether the Personal Data Protection Act's residency rule actually applies to you, plus a practical hardening pass on user access, retention, and breach response inside your existing instance, I can walk through it with you. Contact me for a compliance review →
Frequently asked questions
Does the Personal Data Protection Act 2026 apply to a typical Bangladesh SME running Odoo?
Yes, in the general sense: the Act's baseline obligations around lawful processing, consent, privacy notices, data subject rights, breach notification, and retention controls apply broadly to any organisation processing personal data in Bangladesh, including a mid-size manufacturer or trading company running Odoo for HR, CRM, and sales. The much stricter data residency requirement, which forces a synchronised real-time in-country copy of cloud-hosted data, only applies narrowly to data classified as restricted data or to organisations operating Critical Information Infrastructure. Most SME Odoo deployments fall under the general obligations but not the residency rule, though each business should actively confirm this rather than assume it by default.
What counts as restricted data under Bangladesh's data protection law?
The Act does not hand a business a simple checklist; restricted data is defined in relation to categories of sensitive personal information and to data tied to Critical Information Infrastructure as defined under the Cyber Security Ordinance, 2025. In practice, this generally reaches national identity data at scale, financial and banking records processed by regulated financial institutions, health records, biometric data, and data handled by organisations in the power, energy, healthcare, banking, telecom, and government sectors. A general manufacturer's or exporter's Odoo instance, holding employee HR records, customer contacts, and sales data, is unlikely to meet this bar, but the determination should be made deliberately and documented, not assumed.
Can a Bangladesh company still use Odoo.sh (EU-hosted) after the Personal Data Protection Act 2026?
For the great majority of Bangladesh businesses, yes. The Act's extraterritorial reach means Odoo.sh hosting in the EU does not exempt a Bangladesh company from the law's general obligations, but it also does not by itself trigger a violation, because the data residency requirement (an in-country synchronised copy) only applies when the data qualifies as restricted data or the organisation is Critical Information Infrastructure. A company that has confirmed it does not fall into either category can continue hosting on Odoo.sh or another EU or international cloud, provided it still meets the Act's baseline consent, security, and data-subject-rights obligations. A company that does fall into either category needs a Bangladesh-based synchronised copy regardless of where the primary instance is hosted.
What does the Chief Data Officer requirement mean for a mid-size company using Odoo?
The Act introduces a mandatory Chief Data Officer role for applicable organisations, functioning similarly to a data protection officer under other jurisdictions' privacy laws. For a mid-size Bangladesh company, this rarely means hiring a dedicated full-time compliance executive; it more commonly means formally designating an existing senior staff member (often in IT, legal, or finance) with named responsibility for data protection compliance, privacy notices, breach response coordination, and liaison with regulators, and ensuring that person has real visibility into what personal data Odoo actually stores and who can access it.
What happened to the criminal penalty for data protection violations in Bangladesh?
The original 2025 Ordinance-era framework included a criminal imprisonment penalty that could apply to a managing director for data-subject-rights violations. The Personal Data Protection (Amendment) Ordinance, 2026 amended Section 48 to replace that imprisonment provision with monetary fines only. This significantly changes the risk calculus for company leadership, but it does not remove liability, and monetary penalties under the permanent Act can still be commercially material, particularly for repeated or wilful violations.