What the Cyber Security Ordinance 2025 is
The Cyber Security Ordinance, 2025 came into effect on 21 May 2025, repealing the earlier Cyber Security Act, 2023, which had drawn sustained criticism over press freedom and overbroad enforcement provisions. The new Ordinance restructures the legal framework around two central pillars: the establishment of a National Cyber Security Agency with oversight and enforcement authority, and a defined regime for the protection of Critical Information Infrastructure, including incident response protocols that CII operators are expected to follow.
For an ERP consultant, the Ordinance matters less for its general cybersecurity provisions, most of which describe institutional structure and enforcement mechanics that do not change day-to-day system configuration, and much more for its CII designation, because that designation is the direct trigger for one of the two conditions under which Bangladesh's separate Personal Data Protection Act, 2026 forces a data residency requirement onto a business's cloud hosting architecture. I cover that data protection law in full in Bangladesh Personal Data Protection Act 2026 & Cloud ERP, and this article should be read as its direct companion: understanding whether your business is CII under this Ordinance is a prerequisite to correctly applying that other law's residency rule.
The sectors named as critical
The Ordinance identifies a defined set of sectors as nationally critical for CII purposes: power, energy, healthcare, banking, communication systems, and government data systems. These are the sectors whose disruption would have outsized national consequences, the same underlying logic that drives CII and critical infrastructure designations in most jurisdictions globally.
Power & energy
Grid operators, power generation and distribution companies, and energy infrastructure operators sit squarely within the named scope.
Healthcare
Hospital networks, major diagnostic chains, and health data systems handling patient records at scale are named sector participants.
Banking
Scheduled banks, and by extension much of the regulated financial services sector, fall within scope, and this is the sector most likely to create edge cases for ordinary businesses.
Communication & government systems
Telecom operators and government-operated data systems round out the explicitly named categories.
For the great majority of the manufacturing, trading, RMG, and services businesses I work with, none of these named sectors describe their core business. A garment factory, a trading company, or a pharmaceutical distributor is not power, energy, healthcare, banking, telecom, or government. On a plain reading of the named sectors, most SME Odoo deployments sit outside CII scope entirely.
The honest problem: no closed-form CII definition
Here is where I want to be direct rather than reassuring, because this is exactly the kind of nuance a generic compliance summary glosses over and a working consultant cannot. The Ordinance names sectors, but it does not provide a self-contained, exhaustive definition of what specifically counts as CII within those sectors, at what threshold of scale or national significance an individual organisation crosses into CII designation, or a public register a business can check itself against. Instead, the specific inclusion criteria and the designation process are delegated to government guidelines issued separately from the Ordinance's own text, and those guidelines are described as being updated periodically rather than fixed once and for all.
This is a genuine practical problem, not a hypothetical one. A business cannot read the Cyber Security Ordinance cover to cover and walk away with certainty about its own status if it sits anywhere near the boundary of a named sector, because the boundary itself is defined outside the document a business would naturally consult first. A mid-size fintech-adjacent payment processor, a large NBFI, or a company operating shared telecom infrastructure could plausibly fall inside or outside CII designation depending on guideline details that are not fixed in statute and that a business has to actively track rather than assume.
Note: This ambiguity is a structural feature of the current framework, not an error in this article's research. Where a business's activity plausibly touches one of the named CII sectors, even indirectly, the responsible path is to check current government guidelines directly (or engage counsel who tracks them) rather than rely on a general article, including this one, for a definitive determination. Guidelines described as "periodically updated" mean a determination made today should be re-checked periodically, not treated as permanent.
Why this matters for the data residency rule
The reason I am spending this much space on an ambiguity rather than a clean answer is that the stakes attached to it are real. Under the Personal Data Protection Act, 2026, a business that operates Critical Information Infrastructure (as defined under this Cyber Security Ordinance) is required to maintain at least one synchronised, real-time copy of its cloud-hosted data within Bangladesh's borders, regardless of where its primary system is hosted. That is a nontrivial infrastructure commitment: continuous database replication, filestore synchronisation, and the operational discipline to keep a second live environment in sync with the primary one.
Getting the CII determination wrong in either direction carries a real cost. Wrongly concluding you are not CII when you are exposes the business to a residency-rule violation with the enforcement and reputational consequences that follow. Wrongly concluding you are CII when you are not means committing real infrastructure budget and engineering effort to a compliance requirement that was never actually mandatory, an unforced cost that a careful self-assessment should avoid.
The law does not ask you to guess. It asks you to check, and to keep checking, because the definition it depends on lives in a document that changes.
Self-assessing CII exposure realistically
Given the ambiguity, I use a graduated approach with clients rather than a binary yes/no:
- Is the core business activity power, energy, healthcare, banking, telecom, or government data systems, on a plain reading?
- Does the business provide outsourced or infrastructure services to an organisation in one of those sectors (a data centre serving a bank, a systems integrator for a hospital network)?
- Does the business process payments, extend credit, or otherwise perform functions that overlap with regulated banking or financial services activity, even if not itself a licensed bank?
- Is the business a standard manufacturer, trader, exporter, or professional services firm with no overlap with the named sectors?
For most clients running Odoo for general operations, the honest answer lands in the last category, and the right response is a documented, dated determination rather than an ongoing anxiety about a law that does not, on the facts, apply to them. For clients closer to the banking or financial services boundary, the right response is to treat "probably not CII" as an unverified assumption until a formal check against current guidelines confirms it.
The banking edge case most SMEs miss
Banking deserves specific attention because it is the named CII sector most likely to brush up against businesses that do not think of themselves as financial institutions at all. A trading company operating significant back-to-back letter of credit financing, a business running its own factoring or trade finance desk, or a payment aggregator sitting between merchants and banks may all have some functional overlap with banking activity, even without holding a banking license themselves. This does not automatically mean CII designation, licensed banks and the core banking sector are almost certainly the primary intended scope, but it is precisely the kind of adjacency worth flagging in a formal compliance review rather than dismissing without checking, especially for businesses whose Odoo instance handles a meaningful volume of B2B trade finance or payment processing data.
What this means for Odoo hosting decisions
For the majority of Bangladesh SMEs running Odoo who have genuinely confirmed they sit outside CII scope, the ordinary hosting trade-offs from On-Premise vs Cloud Odoo Bangladesh apply unchanged: choose based on internet reliability, total cost of ownership, and IT staffing, not based on this Ordinance. For businesses operating inside an EPZ or SEZ, the additional bonded-zone compliance layer covered in EPZ & SEZ Compliance in Odoo Bangladesh remains the more immediately relevant regulatory constraint on hosting and data handling, separate from CII status.
For the smaller set of businesses that are CII, or that remain genuinely uncertain after a formal check, the practical hosting posture is to plan for the Personal Data Protection Act's residency requirement proactively: a primary Odoo instance (cloud or on-premise) paired with a synchronised, real-time Bangladesh-based replica, architected before a regulator asks about it rather than after.
| CII status | Hosting implication | Recommended posture |
|---|---|---|
| Clearly not CII (most SMEs) | No residency rule trigger from this Ordinance | Choose hosting on ordinary cost/reliability grounds; document the non-CII determination |
| Adjacent to a named sector (banking-like activity, infra services to CII) | Genuinely ambiguous without a formal check | Seek current guideline confirmation; do not assume either way |
| Clearly CII (bank, power utility, telecom, hospital network) | Data residency rule applies under PDPA 2026 | Architect a synchronised real-time Bangladesh-based replica regardless of primary hosting location |
What CII designation actually requires operationally
It is worth walking through what a CII designation concretely obligates a business to do beyond the data residency rule discussed above, because the residency requirement gets most of the attention in client conversations but is not the only operational consequence. The Ordinance's incident response protocol provisions expect CII operators to have a defined process for detecting, reporting, and responding to cyber incidents, coordinated with the National Cyber Security Agency rather than handled purely internally. For a business whose Odoo ERP sits at the centre of financial, HR, and operational data, this typically means: a documented incident response plan naming specific roles and escalation paths, a defined timeframe for notifying the Agency once an incident is detected (mirroring the breach notification obligations already present in the Personal Data Protection Act), and a technical capability to actually detect an intrusion or data compromise in the first place, which for many Bangladesh SMEs is the weakest link in the chain.
This is where I see the gap between paper compliance and operational readiness most clearly. A business can draft an incident response policy document in an afternoon. Building the actual monitoring capability, database access logging, unusual login pattern detection, and a tested runbook for isolating a compromised Odoo instance without halting the entire business, takes considerably more work, and it is the part that determines whether a CII-designated organisation's compliance is real or cosmetic. For a business genuinely designated CII, I recommend budgeting for this operational build as seriously as the residency rule infrastructure, since a regulator asking about incident response readiness after a breach has already occurred is a far worse position than building the capability proactively.
None of this means a non-CII business should ignore incident response planning either. The scale of the requirement differs, a CII operator needs formal coordination with a national agency, an ordinary SME does not, but the underlying discipline of knowing who does what when something goes wrong is valuable regardless of designation, and cheap to build compared to the cost of improvising during an actual incident.
Security practices worth adopting regardless of CII status
The direction of Bangladesh's regulatory attention on cybersecurity, a dedicated national agency, formal incident response protocols, and a data protection law with real teeth even after the criminal penalty was softened, points toward tightening oversight over time, even if the current CII definition does not reach a particular business today. I advise clients to treat this Ordinance as a signal to adopt sensible security discipline in their Odoo environment regardless of formal designation, since these practices are worth doing on their own merits and reduce the risk of ever becoming a cautionary example that prompts guideline expansion into new sectors.
Concretely, this means: enforcing least-privilege access rights in Odoo's Settings > Users & Companies rather than granting broad admin access by default, enabling two-factor authentication for all users with financial or HR data access, maintaining tested backups per Odoo Backup, Restore & Disaster Recovery Bangladesh, and having a written, even simple, incident response plan naming who does what if unauthorized access is detected. None of this requires CII designation to be worth doing.
Where the guidelines are likely heading
My expectation, watching how comparable CII and critical infrastructure frameworks have matured elsewhere, is that Bangladesh's guidelines will become more granular over time, likely adding clearer thresholds (transaction volume, subscriber count, data volume) that let a business self-assess with more confidence than the current sector-name-only approach allows. Until that granularity arrives, the responsible posture for a consultant advising a client is to treat CII status as a question requiring active, periodic verification against current guidelines, not a box that gets checked once and forgotten, and to build sensible security practices into the Odoo environment regardless of how that specific question resolves.
I would also expect the list of named sectors itself to expand rather than contract as digital infrastructure becomes more embedded in sectors that were not historically considered nationally critical, large-scale logistics and freight, major eCommerce platforms, and payment aggregation being plausible future candidates given how comparable jurisdictions have broadened CII scope over a five to ten year horizon. A business sitting adjacent to a named sector today, even if it clears a self-assessment now, should treat that determination as provisional rather than permanent, and revisit it whenever new guidelines are published rather than waiting for a routine annual compliance review to catch the change.
If you are uncertain whether your business might fall within Critical Information Infrastructure scope, or you simply want your Odoo environment hardened against realistic security risks regardless of formal designation, I can help you work through the determination and the practical security configuration together. Contact me for a review →
Frequently asked questions
What is Bangladesh's Cyber Security Ordinance 2025?
The Cyber Security Ordinance, 2025 came into effect on 21 May 2025, repealing the earlier Cyber Security Act, 2023. It establishes a National Cyber Security Agency and sets out provisions for the protection of Critical Information Infrastructure (CII) and for cyber incident response protocols. It applies broadly to cybersecurity governance in Bangladesh but carries its heaviest specific obligations for organisations designated as CII, covering nationally critical sectors such as power, energy, healthcare, banking, communication systems, and government data systems.
How does a business know if it qualifies as Critical Information Infrastructure in Bangladesh?
This is a genuinely difficult question to answer with certainty from the Ordinance's text alone. The Cyber Security Ordinance names broad sectors (power, energy, healthcare, banking, communication systems, government data systems) as nationally critical but does not provide a fixed, self-contained, closed-form definition of CII within the Ordinance itself. The specific inclusion criteria and designation process are delegated to separate government guidelines that are issued and updated periodically outside the Ordinance's own text. A business cannot fully resolve its CII status by reading the law alone; it needs to check current guidelines and, where genuinely uncertain, seek a formal determination rather than assume non-coverage.
Does the Cyber Security Ordinance 2025 affect where a company can host its Odoo ERP?
Not directly by itself, but it interacts closely with the Personal Data Protection Act 2026's data residency rule, which requires a synchronised real-time in-country copy of cloud-hosted data for organisations processing restricted data or operating Critical Information Infrastructure. Since CII status under the Cyber Security Ordinance is one of the two triggers for that residency requirement, a business's CII determination under this Ordinance directly decides whether its ERP hosting choice is constrained by the separate data protection law.
Which businesses are most likely to be affected by Critical Information Infrastructure rules in Bangladesh?
The sectors named unambiguously in the Ordinance, power, energy, healthcare, banking, communication systems, and government data systems, cover organisations that most Bangladesh SMEs are not part of. Banking is the sector most likely to create indirect relevance for ordinary businesses, since companies handling significant B2B trade finance, payment processing, or operating as payment service providers may fall closer to this boundary than a typical manufacturer or trading company. Most non-financial SMEs running Odoo for standard ERP functions (accounting, inventory, HR, CRM) are unlikely to be designated CII, but should still confirm this against current guidelines rather than assume it.
Should a business that isn't CII still care about the Cyber Security Ordinance?
Yes. Even businesses that are clearly not CII should treat the Ordinance's direction of travel, mandatory incident response readiness, a national cybersecurity oversight body, and rising regulatory attention to cyber risk, as a signal to adopt sensible security practices regardless of formal designation: access control discipline in the ERP, tested backups, a basic incident response plan, and monitoring for unauthorized access. Regulatory scope in this area has consistently expanded over time in comparable jurisdictions, and businesses that build these practices proactively will not be caught flat-footed if guidelines are later updated to bring more sectors into CII scope.