Not as a single statute. For banks and financial institutions, the main source is Bangladesh Bank's ICT security guidelines and related circulars, which address governance, risk management, outsourcing, cloud, business continuity and incident reporting. Payment providers have licence-based requirements, and the securities, insurance and telecommunications regulators issue their own rules. Cyber security legislation and the Personal Data Protection Act 2026 apply more widely. In practice, digital operational resilience in Bangladesh is assembled from these sources, which is why a clear map of which rules apply to which service is the essential first step for any compliance programme.

At a minimum, the contract should give the bank clear service levels, defined security standards, the right to audit or rely on independent assurance reports, access for Bangladesh Bank, prompt incident notification, controls on subcontracting, data location and segregation commitments, business continuity and disaster recovery obligations, and meaningful exit assistance with data return. Bangladesh Bank approval or notification may also be needed for certain cloud and outsourcing arrangements. We compare the provider's terms with these requirements, negotiate what can be negotiated and help the bank document compensating controls for what cannot be changed. That supports digital operational resilience.

The EU regime applies directly to European financial entities, not to Bangladeshi providers. However, those entities must include specific terms in contracts with ICT service providers, so Bangladeshi software, BPO and managed service companies serving them receive detailed clauses on security, audit, incident cooperation, testing, subcontracting, data location and exit. Accepting these terms without review can expose a provider to uncapped liability and heavy audit costs. We explain which requests are genuinely required, which go further than needed, and how to price, cap and limit the obligations so the relationship remains commercially sustainable for both sides.

Contain the incident, preserve evidence and convene the response team, including legal. Early legal tasks include assessing whether regulators, customers or data subjects must be notified and when, notifying insurers, preserving logs and communications, controlling external statements, and checking vendor contracts for notification and cooperation duties. Privilege should be considered when forensic experts are engaged. Decisions should be recorded with reasons, because regulators and courts will later examine what management knew and when. A prepared playbook makes these first hours far more manageable and reduces the risk of inconsistent statements. Digital operational resilience depends on rehearsal.

Sometimes, but only after checking them against the regulatory expectations that apply to the service. Large global vendors often refuse bespoke drafting, yet many offer financial services addenda that cover audit, regulator access and exit. Where gaps remain, the board or a delegated committee should decide whether to accept the risk, seek an alternative provider or add compensating controls such as stronger monitoring, additional backup or a secondary provider. Regulators generally expect that decision to be informed and documented. Digital operational resilience is weakened most when critical contracts are signed without anyone recording what was missing.

Concentration risk arises when many critical services depend on a single provider, data centre, network or platform, or when much of a sector relies on the same few vendors. A failure at that point can disrupt many functions at once. Regulators increasingly ask firms to identify and manage these dependencies, including fourth parties behind their direct vendors. For digital operational resilience planning, this means understanding where alternatives exist, how quickly services could move, and whether contracts support a realistic exit. We help clients map concentration risk and reflect it in procurement decisions and board reporting.

Exit planning should start before signing. The contract should require the vendor to provide transition assistance, return data in usable formats, continue service for an adequate period after termination, and cooperate with a successor provider. Escrow of source code may be relevant for critical software. Termination rights should cover regulatory direction, serious security failures and change of control. Without these protections, an organisation can be locked in to a failing provider. We draft exit provisions, including data return formats, and help clients prepare practical exit plans that regulators can review and that operational teams can actually follow.

Formal regulatory obligations are heaviest in banking, payments, capital markets, insurance and telecommunications. Other businesses face resilience duties through cyber security legislation, particularly where systems are designated as critical information infrastructure, and through data protection law, customer contracts and directors' general duties of care. Exporters, manufacturers and hospital groups increasingly receive resilience requirements from overseas customers and insurers. For these organisations, the same disciplines of governance, contract control, incident readiness and exit planning reduce disruption and the legal exposure that follows a serious outage. Digital operational resilience is a shared discipline across all sectors.