Patient Data in the Cloud: Bangladesh’s 2026 Data Protection Law for Hospitals and Healthtech

Summary

The premise needs correcting before it becomes a compliance plan. Bangladesh does have a Personal Data Protection Act, 2026, but it is not a single switch that makes every cloud arrangement lawful or unlawful. The Act replaced the 2025 personal-data ordinance, treats health information as sensitive personal data, allocates responsibility between a data-fiduciary and a processor, regulates retention and security, and creates a framework for overseas transfers. Some enforcement and institutional provisions remain subject to deferred commencement, rules, regulations, standard operating procedures and implementation by the National Data Management Authority. This article maps the practical position as at 23 September 2026. It separates what the statute already says from what a hospital should contract for now and what remains unsettled.

A useful starting point is TRW’s Data Protection & Privacy practice page, which frames the analysis around the data lifecycle, organisational roles, transfers and developing regulatory detail. The legal question is not “Is the database in the cloud?” It is: who decides why each item is processed, who can access it, where copies and logs exist, how long they remain, and what happens when the system fails?

The commercial problem: the cloud is not the legal answer

A hospital, diagnostic chain or health platform rarely has one patient database. The record may begin in a registration portal, move through an electronic medical record, generate laboratory and imaging files, pass to a billing or insurer interface, appear in a patient app, and be copied into backups, disaster-recovery systems, support tickets and analytics environments. A cloud contract may then permit subcontractors in several countries to administer the service. A doctor may access the same record from a personal device. A group company may use de-identified or pseudonymised records for product development. Each event is a form of processing.

The operational choice is therefore not “local server or foreign cloud”. It is whether the organisation can show a defensible chain from purpose and legal basis to access, security, retention, transfer and deletion. The Act’s definition of processing is deliberately broad. It includes collection, recording, organisation, storage, retention, transfer, retrieval, use, disclosure, alteration, restriction and erasure.[1] A vendor that never reads the clinical note may still process it by storing, backing up or transmitting it.

The financial exposure is also wider than a fine. A weak allocation of responsibility can interrupt clinical operations, trigger patient complaints, complicate a hospital acquisition, breach a lender’s information-security covenant, and leave a provider unable to prove what was deleted. A cloud service level may promise uptime while saying almost nothing about the confidentiality of a psychiatric note, the deletion of an MRI image, or the nationality and location of a support engineer who can access a production environment.

The practical answer is a joined-up programme: classify the data, map the flow, assign the legal roles, document a processing basis, negotiate vendor controls, set an evidence-backed retention schedule, and test the incident route before the first serious incident. That programme should be designed against the Act, but it should not pretend that every delegated power has already been implemented.

What changed: Bangladesh now has a 2026 Act, not merely a proposal

The topic brief refers to “Bangladesh’s 2026 Data Protection Law” as a question. Official sources now support that proposition, with an important timeline. The Bangladesh Laws database records the Personal Data Protection Act, 2026 as Act No. 63 of 2026. It also records that the Personal Data Protection Ordinance, 2025 and the Personal Data Protection (Amendment) Ordinance, 2026 have been repealed, while actions and proceedings taken under them are treated as actions under the Act.[1] The Government Press record confirms that the earlier Ordinance No. 61 of 2025 was gazetted on 6 November 2025.[2]

The Act is deemed effective from 6 November 2025, except section 23 and sections 31 to 35. Those provisions are to become effective on a date that the Government determines by Gazette after the statutory period described in section 1(3). On the official materials opened for this article, no Gazette fixing that later commencement date was identified as at 23 September 2026. That is a point for live pre-publication checking, not a reason to describe the entire Act as dormant.[1]

This distinction matters. The Act’s core rules on lawful processing, sensitive data, processor responsibility, privacy, security, retention and records are already the relevant statutory architecture. The deferred provisions include the Chief Data Officer obligation in section 23 and the complaints, administrative fines and compensation machinery in sections 31 to 35. A hospital should not wait for the first administrative penalty to establish controls. It should also not tell management that the statutory fine regime is already fully operative when the commencement position says otherwise.

The Act sits beside two other 2026 statutes that affect the architecture. The National Data Management Act, 2026 establishes a National Data Management Authority and describes governance principles including data classification, access control, security, privacy, interoperability, minimisation, retention and destruction.[3] The Cyber Security Act, 2026 treats cloud computing, data centres and digital infrastructure as part of the cyber-security environment. It defines Critical Information Infrastructure (CII) by reference to infrastructure whose compromise could affect public safety, economic security, public health, national security, territorial integrity or sovereignty.[4] A hospital is not automatically CII merely because it holds health records; CII status depends on a government declaration and the statutory framework. That status should nevertheless be checked for public or nationally significant systems.

The result is a genuine 2026 data-protection framework, but an incomplete operational picture. The Act supplies duties and powers. Regulations must still fill matters such as request procedures, breach details, standards, classification, transfer processes and the scope of significant data-fiduciaries. The National Data Management Authority’s actual institutional capacity and published guidance also require verification over time.

Health data is sensitive, and the definition is broader than the diagnosis field

Section 2 of the Act defines “sensitive personal data” to include health-related data. “Health data” covers information about physical or mental condition, records of past, present or future health, ancillary information connected with healthcare, and personal data collected during registration, payment or the provision of health services.[1] That reaches further than a doctor’s diagnosis. Patient identity, appointment history, insurance or payment information connected to care, laboratory reports, images, referral notes, biometric verification and a symptom entered in a triage chatbot may sit inside the same protected flow.

The classification should be performed by data element and use case, not by the name of the application. A billing module can contain health data. A call recording can reveal a condition. A device identifier can become personal data when connected to a patient profile. A tokenised research dataset may still be personal data if the organisation or its processor can reasonably reconnect it to a person. Pseudonymisation reduces exposure; it does not automatically remove the data from the Act.

Section 7 permits processing sensitive personal data on specified grounds. These include specific consent, a contract involving the data subject, employment or social-security obligations, healthcare duties by a health worker and emergency medical responsibilities, legal duties, and information voluntarily made public by the data subject.[1] The healthcare ground is not a blank cheque. It supports treatment and urgent care; it does not silently authorise advertising, unrelated data brokerage or indefinite product development.

The distinction between primary care and secondary use should appear in the system design. A hospital may need to process a patient’s health record to provide treatment. It may need a different basis, notice and governance route to train a diagnostic model, send a commercial wellness campaign, share a case study or combine records with a group company’s dataset. A single acceptance tick box for “all services, research, partners and promotions” is a poor substitute for a purpose-specific analysis.

The Bangladesh Medical & Dental Council’s Telemedicine Guidelines remain a practical professional reference for digital care. They require registered doctors to identify the patient, obtain explicit consent, assess whether telemedicine is appropriate, preserve privacy and confidentiality, and document digital consultations. The guidelines also require attention to emergency referral, records and the technology platform.[5] They do not replace the Act, and they do not resolve every cloud or cross-border question, but they show the clinical standard against which a platform’s workflows will be judged.

Consent is important, but it is not the only lawful basis

The Act says consent must be voluntary, specific, clear and withdrawable. The data subject must be informed of the purpose, retention period, transfer and withdrawal process, and the fiduciary bears the burden of proving that consent was properly obtained.[1] In a patient portal, that means a privacy notice and consent record should be linked to the actual collection event. It should be possible to identify the wording shown, the language used, the time, the channel, the person or guardian acting, and the purposes selected.

Consent should not be forced where it is unnecessary. Section 5 also identifies lawful bases and interests, including performance of a contract, steps requested before a contract, legal claims, vital interests, employment and social-security rights, voluntary public disclosure and certain harm-prevention circumstances. Section 24 provides consent exemptions for, among other matters, national security, court orders, crime prevention, tax enforcement, public health, medical or medical-public-interest purposes, private activities, statistical and scientific research and certain public-interest publication.[1]

The exemption does not remove the other obligations. Section 24(2) says that exemption from consent does not exempt processing, storage, retention or disclosure from the applicable rules. In practical terms, an emergency department can act to protect life without waiting for a perfect consent click, but it still needs access control, documentation, confidentiality and a defensible retention decision.

For children or persons unable to consent, section 9 requires consent from a parent, legal guardian or authorised decision-maker and requires the processing to protect the person’s rights and interests. Health platforms should therefore distinguish the patient, the account holder and the person giving consent. A parent’s portal account must not become an uncontrolled window into a teenager’s entire record where the clinical and legal context requires a narrower disclosure.

Withdrawal is operational, not merely textual. Section 13 permits withdrawal in relation to storage, processing or automated decisions and provides a route for erasure subject to exceptions. The Act also contemplates system-wide propagation of approved corrections and deletions, including mirrors, caches, backups, disaster recovery, test environments and migration datasets.[1] That is a demanding requirement for legacy architecture. A hospital should know which copy is authoritative, which copies are legally required, which copies are encrypted backups and how a deletion or correction request is recorded when immediate physical erasure is technically impossible.

The hospital is usually the fiduciary; the cloud provider is usually a processor

The Act calls the organisation deciding the purpose or supervising processing the data-fiduciary. A person processing personal data on the fiduciary’s behalf is a processor. A hospital ordinarily determines why patient information is collected and how it supports care. It will therefore usually be the fiduciary for its patient record system. A healthtech platform may be a fiduciary for its own registration, matching, clinical-support or account purposes. A cloud provider that stores data only on documented instructions will commonly be a processor for that service.

The labels do not decide the question. A vendor may become a separate fiduciary for information it uses for its own purposes, such as independent marketing, behavioural analytics or model training. A hospital group may have joint responsibility where the group sets common purposes and controls the platform. The analysis must follow the facts, not a standard procurement template.

Section 8 is commercially significant because processing by a processor on the fiduciary’s behalf is treated as processing by the fiduciary, and the fiduciary remains responsible for taking reasonable measures to ensure the processor complies.[1] The hospital cannot answer a regulator, patient or board by saying “the cloud provider did it”. The provider remains responsible for its own security obligations, but the hospital must choose, instruct and supervise it properly.

A cloud agreement should therefore answer at least these questions:

1. What data categories may be uploaded, and may the provider use them for anything other than the documented service?
2. What locations host production, backups, logs, support tools and disaster-recovery copies?
3. Which subcontractors and support personnel may access the environment, from which countries and under what approvals?
4. What encryption, key-management, identity, privileged-access, logging, vulnerability-management and resilience controls apply?
5. How quickly must the provider notify the hospital of an incident, suspected compromise, government request or service outage?
6. How will the provider assist with access, correction, portability, objection, deletion, audit and regulatory requests?
7. What happens at expiry, termination, migration, insolvency or a provider change, including certified deletion and return of data?

The agreement should not promise a hospital an audit right that the provider cannot operationally support. It should instead provide credible evidence mechanisms: independent assurance reports, targeted audit rights, inspection after an incident, information-security questionnaires, subprocessor notice, penetration-test summaries and a clear chain of responsibility.

Hospitals and healthtech businesses should also review the provider’s standard online terms. A service may advertise “data residency” while allowing global support access. It may delete the main database while retaining immutable backups for a defined period. It may use metadata, diagnostic logs or prompts for service improvement. Those are separate processing questions. The contract needs a hierarchy: the healthcare customer’s instructions and data-protection schedule should not be silently overridden by a generic acceptable-use or product-improvement clause.

TRW’s Data Centres, Cloud & Digital Infrastructure practice page describes the associated commercial questions: capacity, subcontracting, audit, service levels, migration, exit, continuity and cross-border interfaces. A cloud contract is both a data-protection instrument and an operational-continuity document.

Overseas hosting and remote access require a transfer map

The Act has extra-territorial reach for specified Bangladesh-connected processing, including processing outside Bangladesh connected with providing goods or services to, monitoring or profiling a person in Bangladesh.[1] A foreign parent, global electronic-medical-record supplier or overseas support team should not assume that the physical location of the patient or server ends the analysis.

Section 29 provides a framework for classification and overseas transfer. The Government may classify personal data as public, internal, confidential or restricted. A transfer may be supported by consent, a contract involving the data subject, or a consent-connected business, education, emigration or immigration matter. The Act also says that legally transferable data may be sent only to locations with the technology and equipment prescribed for proper storage, and that large cross-border transfers of sensitive personally identifiable data must be notified to the Authority.[1]

The difficult point is implementation. The Act reserves transfer procedure, technology and tools to regulations and standard operating procedures. As at the checked date, the prudent position is not to invent a universal “approved country list” or claim that every foreign cloud region is prohibited. Instead, the hospital should document the destination, access route, data categories, volume, purpose, contractual safeguards, encryption, recipient role, onward transfers and deletion mechanics. It should ask whether remote support from another country is itself a transfer or access event under the developing framework and treat it as a controlled risk pending clearer guidance.

The transfer map should include more than production. Include analytics, telemetry, crash reports, email, ticketing, identity management, security monitoring, vendor training environments, data lakes, back-up vaults and clinician access. A record can leave Bangladesh through a support ticket even when the primary database remains in Dhaka.

A sensible contract separates storage geography from access geography. It specifies permitted regions, requires approval for a new region, restricts support access to named roles, prohibits onward disclosure except on documented instructions, and requires assistance with a legally valid government request. It should also address conflicts: the provider may be subject to foreign disclosure law, while the hospital owes duties under Bangladesh law and professional confidentiality. No contract can guarantee that a foreign authority will never demand access, but it can create notice, challenge, minimisation and transparency commitments where lawful.

Retention is a clinical, legal and technical design decision

Section 18 says a fiduciary should not retain personal data beyond the period prescribed by regulation for the purpose for which it was processed, subject to specified public-interest, scientific, historical or statistical circumstances and safeguards.[1] Section 19 requires records concerning processing to be maintained in a register for at least five years unless another law specifies otherwise. These are related but not identical obligations. The patient record may have a clinical or sector-specific retention need; the processing register is evidence of what the organisation did.

A retention schedule should be built by record type. A discharge summary, pathology image, prescription, consent record, identity-verification log, access log, billing record, call recording, research dataset and backup snapshot should not inherit one blanket period. The schedule should state the purpose, owner, legal or operational trigger, hold mechanism, deletion method, backup treatment and exception for litigation, investigation, patient safety or statutory retention.

Deletion must be realistic. “Delete on request” is not a plan if the vendor retains encrypted backups for 90 days, if a laboratory interface has a separate archive, or if an immutable audit log records the event. A defensible process can distinguish live deletion, suppression from active use, expiry of backups and preservation under a documented legal hold. The patient-facing explanation should be clear, and the internal record should show what was deleted, what was retained, why, by whom and when.

The five-year processing-record obligation makes evidence a board issue. A hospital should be able to produce its data inventory, privacy notices, consent logs, processor list, transfer register, access reviews, incident records, risk assessments, retention decisions and deletion attestations. If an organisation cannot show these records, it may be unable to demonstrate that its cloud model is controlled even where no breach occurred.

Security and breach response: prepare before the notification clock exists

Section 17 requires technical and organisational measures to protect security, integrity and confidentiality and to prevent unlawful or accidental destruction, loss, misuse, alteration, disclosure or access. The Act expressly identifies pseudonymisation, encryption, confidentiality, integrity, availability, resilience, recovery, periodic risk assessment, testing, evaluation, monitoring and updating as relevant measures.[1]

For patient data, “encrypted” is not enough. The hospital should test key management, privileged access, identity lifecycle, multi-factor authentication, service accounts, export controls, API authentication, network segmentation, endpoint protection, immutable logging, backup restoration and supplier access. It should separate clinical production from development and test data. It should restrict bulk export and investigate unusual access to high-risk records. It should make emergency access possible but exceptional, logged and reviewable.

Section 20 requires notification to the Authority where a personal-data breach is likely to cause significant harm, in the form, manner and time prescribed by regulation.[1] The provision is substantive, but the precise deadline and format remain tied to delegated detail. A contract should therefore require rapid notice to the hospital, often within hours of a credible incident, so that the hospital can assess the statutory threshold, patient-safety impact, professional duties, insurance requirements, law-enforcement engagement and any need to notify affected people.

The incident playbook should name a clinical lead, privacy or legal lead, IT/security lead, communications lead and vendor manager. It should preserve logs and evidence, contain the incident without destroying proof, identify affected records and recipients, assess whether care was disrupted, coordinate with the processor, document decisions and avoid premature assurances. A ransomware event may be both a confidentiality incident and an availability incident. A misdirected email may be smaller in volume but severe in sensitivity. The response should be risk-based and recorded.

The Cyber Security Act adds a separate cyber-security perimeter. It establishes national and sector response structures and contemplates CII-specific teams and reporting where an infrastructure is declared CII.[4] A healthcare operator should establish whether it or a connected public system has been designated. It should not assume that compliance with the Personal Data Protection Act satisfies cyber-security, medical-professional, contractual or insurance requirements.

A bank or payment institution in the healthcare chain may also impose additional controls. Bangladesh Bank’s official regulations list identifies its 2023 Guidelines on Cloud Computing, 2023 ICT Security Guideline and 2026 Cybersecurity Framework.[6] The cloud guideline directly governs regulated financial organisations, not every hospital. It becomes relevant where the hospital is part of a regulated financial service, uses a bank-operated platform, or negotiates payment and outsourcing interfaces that incorporate those requirements. It is a useful benchmark for due diligence and resilience, not a universal hospital rule.

The implementation plan: convert the Act into a defensible operating model

A serious programme can be sequenced without waiting for every regulation.

First, create a data and systems inventory. List patient-facing channels, clinical systems, laboratories, imaging, pharmacy, billing, insurance, research, call centres, apps, APIs, backups, logs, test environments and support systems. Record the categories, owners, users, destinations, copies and retention points.

Second, assign roles and purposes. For each flow, identify the fiduciary, processor, joint participant or independent recipient. Record the purpose and legal basis. Separate treatment, administration, payment, safety, research, marketing and product-development purposes. Where the answer is uncertain, flag it rather than hiding it under “business operations”.

Third, classify sensitivity and transfer exposure. Health data is sensitive under the Act. Add identity, biometric, genetic, children’s, location and financial combinations. Map overseas storage and remote access. Record the minimum data required for each use.

Fourth, remediate patient-facing transparency. Privacy notices should explain categories, purposes, retention, recipients, transfers, rights and contact routes in a comprehensible form. Consent should be granular where consent is the basis. Emergency and healthcare processing should be documented as such rather than disguised as consent.

Fifth, rebuild vendor contracts. Put processing instructions, confidentiality, security, subprocessors, assistance, audit evidence, incident escalation, transfer controls, return, deletion and exit in one coherent schedule. Align the agreement with the technical architecture. A promise to delete is not credible unless the system can execute it.

Sixth, test rights and incidents. Run a patient access request, correction request, consent withdrawal, deletion request, export, lost-device scenario, insider-access scenario, ransomware scenario and vendor outage. Measure the result. The test should include the backup and disaster-recovery environment.

Seventh, prepare governance for the deferred provisions. The Act contemplates significant data-fiduciaries, independent audits, Chief Data Officers, complaints, administrative fines and compensation. The relevant commencement and designation details must be checked against later Gazettes and regulations. A large hospital or national health platform should design a responsible owner and reporting route now, without representing that section 23 or sections 31–35 are already in force if the official commencement position has not changed.

TRW’s Pharmaceutical & Healthcare practice page places digital health, professional governance, facility models, contracts and data in the same commercial picture. That is the right approach. Data protection is not a privacy-policy exercise detached from clinical responsibility, procurement, patient safety and service continuity.

What the law says, what practice requires and what remains uncertain

Question	Current position as at 23 September 2026	Practical response
Is there a 2026 data-protection law?	Yes. The Personal Data Protection Act, 2026 replaced the 2025 and 2026 ordinances.	Update legal registers, notices, contracts and governance documents to the Act.
Is health data sensitive?	Yes. Health-related data is expressly included in sensitive personal data.	Treat clinical, diagnostic, registration and care-linked payment data as high risk.
Is the whole Act deferred?	No. Core processing, security, retention and processor rules are deemed effective from 6 November 2025.	Do not wait for enforcement machinery before implementing controls.
Are all sanctions and complaints operative?	Sections 31–35 are subject to deferred commencement under section 1(3), pending the prescribed Government date.	Verify the latest Gazette before publication and before relying on fine or compensation exposure.
Must every hospital appoint a Chief Data Officer now?	Section 23 concerns significant data-fiduciaries and is also deferred under section 1(3).	Allocate ownership now; confirm designation and commencement before stating a statutory appointment duty.
Is foreign cloud hosting automatically unlawful?	The Act regulates classification and transfers but leaves important procedure to regulations and SOPs.	Map destinations and access, contract safeguards, minimise data and re-check the official transfer rules.
Is a cloud provider solely liable?	The fiduciary remains responsible for processor activity on its behalf.	Conduct due diligence and retain supervision, evidence and incident control.
Is a breach deadline fixed in the Act?	The Act requires notification for significant-harm breaches, with form and timing prescribed by regulation.	Contract for immediate escalation and maintain a tested breach playbook.

The table is deliberately conservative. It distinguishes statutory text from implementation. That is more useful than claiming certainty where the Act itself reserves important details to future instruments.

What to do next

A hospital or healthtech business should commission a focused cloud and patient-data review before renewing a major hosting contract, moving to a foreign region, launching a patient app, buying a diagnostic chain or connecting to a shared health-record exchange. The review should produce a system-and-data map, role and purpose matrix, transfer assessment, retention schedule, vendor contract issues list and incident plan. It should also identify which conclusions depend on a future regulation, a Government designation or a fact that has not yet been verified.

For a Bangladesh or cross-border matter, use TRW’s contact route to start with the context and the decision that needs to move next. Please send only non-confidential information initially. Do not submit patient records, credentials, privileged material or time-sensitive incident details through a public contact form.

Conclusion

Cloud adoption is not the hard legal decision. Uncontrolled responsibility is. Bangladesh’s 2026 Act makes health data sensitive, keeps the hospital accountable for processors, requires security and retention discipline, and creates a transfer framework that will depend partly on later implementation. The safest commercial posture is neither “keep everything in Bangladesh” nor “the vendor handles compliance”. It is a documented model in which every copy, access route, purpose, vendor, destination and deletion decision has an owner and an evidence trail. Build that model now, and mark the deferred provisions and regulatory gaps for live review.

Frequently asked questions

1. Does Bangladesh’s Personal Data Protection Act, 2026 apply to a foreign cloud provider?

It can apply where the processing has the Bangladesh connection described by the Act, including processing outside Bangladesh linked to providing goods or services to, monitoring or profiling a person in Bangladesh. The provider’s role depends on its purposes and instructions. A foreign provider acting for a Bangladesh hospital may be a processor, but a provider using records for its own purposes may require a separate role analysis.

2. Can a Bangladesh hospital store patient records on servers outside Bangladesh?

The Act creates a framework for classification and overseas transfers; it does not support a blanket conclusion that every foreign region is either approved or prohibited. The hospital should map the categories, destination, access, recipient, purpose, security, contractual safeguards and onward transfers. It should also check the regulations, standard operating procedures and any Government or Authority classification applicable at the time of the transfer.

3. Is patient consent always required for processing health data?

No. The Act recognises specific consent and other lawful bases, including contractual necessity, vital interests, legal obligations, healthcare duties and emergency medical responsibilities. Consent remains important for many patient-facing and secondary uses, and it must be specific, informed, voluntary and withdrawable. An exemption from consent does not remove security, confidentiality, retention or disclosure obligations.

4. Who is responsible if a cloud vendor loses a hospital database?

The answer depends on the facts and the vendor’s role, but the hospital cannot simply transfer away its responsibility. The Act treats processor activity on the fiduciary’s behalf as processing for which the fiduciary remains responsible and requires reasonable measures to ensure processor compliance. The contract should provide rapid notice, investigation support, evidence preservation, remediation and assistance with affected-person and regulator decisions.

5. How long may a hospital retain patient data?

The Act says personal data should not be retained beyond the period prescribed for the processing purpose, subject to specified exceptions. It also requires processing records to be kept in a register for at least five years unless another law provides otherwise. A hospital should create a record-specific schedule and distinguish live records, statutory archives, audit logs, legal holds, backups and research datasets.

6. Must every hospital appoint a Chief Data Officer in 2026?

Section 23 requires Chief Data Officers for significant data-fiduciaries, but section 1(3) makes section 23 one of the provisions subject to deferred commencement. The designation criteria, commencement notice and later regulations must be checked before stating that every hospital has a presently operative statutory appointment duty. Large or nationally significant operators should nevertheless assign internal ownership and prepare for the governance model.