Cloud Computing as a Strategic Technology

Cloud computing has evolved from a niche IT concept into the backbone of modern enterprise infrastructure. As an umbrella term, it describes on-demand access to shared computing resources — servers, storage, databases, networking, software — delivered over the internet. Rather than owning physical hardware, organisations rent capacity from large-scale providers and pay only for what they use.

For developing economies, the promise is significant. Cloud services offer a cost-effective path to deploying and managing large volumes of IT resources without the capital expenditure required to build on-premises data centres. They also enable participation in newer paradigms such as blockchain, where participants need to record information in decentralised ledgers and access it remotely from multiple locations.

The State of Cloud Adoption in Bangladesh

Major cloud service providers — including AWS (Amazon Web Services), Microsoft Azure, Google Cloud, and Oracle — are active in Bangladesh through local partner companies. Demand is growing, particularly in the private sector, driven by rapid digital adoption across a large and increasingly connected population.

Microsoft has been publicly vocal about its ambitions in the market. At a Microsoft Cloud Innovation Summit titled “Transforming Bangladesh with Cloud” held in Dhaka, Sook Hoon Cheah, President of Microsoft Southeast Asia New Markets, highlighted the private sector as a primary growth area. Sonia Bashir Kabir, former Managing Director of Microsoft Bangladesh, pointed to the country’s scale — over 160 million people generating large volumes of data — as a major driver of business potential.

However, a key constraint shapes market strategy: the Government of Bangladesh restricts the hosting of government data outside the country. This limits cloud providers largely to private-sector engagements for now.

Key Barriers to Cloud Adoption

Several structural and regulatory challenges slow broader cloud adoption in Bangladesh and in similar developing markets:

• Low awareness: Many organisations, particularly small and medium enterprises, lack a clear understanding of what cloud computing is, how it works, and what risks and benefits it carries.
• Absence of a dedicated legal framework: No legislation directly governs or regulates cloud computing services. The Government of Bangladesh Information Security Manual (GoBISM) 2016, produced by the Bangladesh Computer Council under the ICT Ministry, provides guidelines and recommendations for government agencies, but its use is voluntary and not mandated across sectors.
• Cross-border data restrictions: Cloud infrastructure is inherently global. Data typically traverses and resides in servers outside the originating country. Bangladesh’s Bank Companies Act, 1991 (Section 12) restricts banks from removing records and documents related to their business to locations outside Bangladesh without prior approval from Bangladesh Bank. Whether this restriction applies to cloud-hosted data is legally ambiguous. Non-banking private organisations are not subject to the same explicit restriction, but the regulatory uncertainty itself creates hesitation.
• No comprehensive data privacy law: Without strong data privacy legislation, personal data hosted on cloud infrastructure may be vulnerable to unauthorised disclosure by cloud providers. This is both a legal gap and a reputational risk for organisations handling sensitive customer data.
• Cybersecurity exposure: Large-scale national and international cyberattacks remain a persistent threat. Without a national cybersecurity strategy tied to cloud adoption, organisations face significant residual risk.

Global Data Protection Standards as a Reference Point

Established economies have moved decisively to create regulatory frameworks that enable cloud adoption while protecting individual rights. Two prominent examples are worth examining:

The EU General Data Protection Regulation (GDPR)

The GDPR, which came into effect in May 2018, sets a comprehensive standard for how personal data must be collected, stored, processed, and transferred. It applies not only to EU-based organisations but to any entity processing data about EU residents. Key principles — purpose limitation, data minimisation, storage limits, security obligations, and rights of access and erasure — are directly relevant to how cloud providers must handle data on behalf of enterprise customers.

APEC Cross-Border Privacy Rules (CBPRs)

Developed by the 21 member economies of the Asia-Pacific Economic Cooperation (APEC) forum, the CBPR system provides a mechanism enabling organisations to demonstrate compliance with a common privacy standard when transferring data across borders within the region. It is designed to balance privacy protection with the practical need for data to flow freely to support digital trade and services.

The BSA Cloud Computing Scorecard

The Software Alliance (BSA) publishes a Global Cloud Computing Scorecard that ranks countries on their policy readiness for cloud adoption. The 2018 edition assessed policy areas including privacy law, security frameworks, cybercrime legislation, intellectual property protection, standards and interoperability, free trade in cloud services, and IT infrastructure.

The Scorecard found that most high-scoring countries had comprehensive data protection frameworks in place and had established independent privacy regulators. Several countries — including Brazil, Thailand, China, India, Indonesia, and Vietnam — were identified as having no comprehensive data privacy law or only very limited protections in place at the time of publication. Canada and Mexico ranked highest in the privacy dimension.

The clear implication: privacy law is not just a compliance requirement. It is an enabler of cloud adoption. Without it, organisations are reluctant to migrate workloads, and providers are reluctant to commit investment.

What a Sound Legal Framework for Cloud Adoption Should Include

For any government seeking to unlock the benefits of cloud computing — cost efficiency, scalability, innovation — while managing its risks, a comprehensive policy and legal framework is a prerequisite. That framework should address the following areas:

• Data privacy legislation: Define how personal data may be collected, processed, stored, and transferred, including rights for individuals to access, correct, and delete their data.
• Cross-border data transfer rules: Establish clear conditions under which data may be hosted or processed outside the country, replacing ambiguous restrictions with workable compliance mechanisms.
• Data encryption and security standards: Mandate minimum technical controls, including encryption at rest and in transit, access management, and regular security audits.
• Data backup, recovery, and archiving: Require cloud providers and enterprise users to maintain verifiable backup and recovery capabilities for critical data.
• Data portability: Ensure organisations can retrieve and migrate their data if they switch providers, avoiding lock-in and supporting competitive markets.
• Cybercrime legislation: Enact and enforce laws that criminalise unauthorised access, data theft, and sabotage of cloud infrastructure.
• National cybersecurity strategy: Define responsibilities across government agencies, cloud providers, and enterprise users for detecting and responding to incidents.
• Risk assessment requirements: Mandate that organisations conduct formal risk assessments before migrating to cloud services, and that providers verify controls are properly implemented before onboarding customers.
• Harmonisation with international standards: Align domestic rules with frameworks like GDPR and APEC CBPRs to reduce barriers to cross-border services and attract investment.

Avoiding Overregulation

A critical balance must be struck. Overly restrictive policies — those that effectively prohibit cross-border data flows or impose disproportionate localisation requirements — create trade barriers and stifle the cloud market rather than protecting citizens. Regulation should be designed to build trust and manage genuine risk, not to prevent adoption.

Cloud services’ value depends fundamentally on users trusting that their data will be handled as agreed. Providers must ensure that all controls are properly implemented before onboarding enterprise customers, and that data is not used or disclosed beyond the agreed purposes. Governments must create a legal environment where that trust is enforceable.

Summary

Cloud computing offers developing economies a genuine opportunity to modernise their IT infrastructure, reduce costs, and participate in global digital services. But the technology cannot deliver on that promise without a clear legal and regulatory foundation. Data privacy law, cross-border transfer rules, cybersecurity standards, and a risk-based compliance approach are not optional extras — they are the preconditions for sustainable, trustworthy cloud adoption. Policymakers who invest in getting this framework right will unlock far greater returns from cloud investment than those who leave the legal landscape ambiguous.

When Bad Code Has Real-World Consequences

In March 2018, one of Uber’s autonomous test vehicles struck and killed a pedestrian in Tempe, Arizona. The incident became one of the most scrutinized software-related accidents in recent memory. Investigations revealed a troubling combination of factors: the safety driver behind the wheel was reportedly watching a streaming video on a personal device instead of monitoring the road, and the vehicle’s self-driving sensor system failed to correctly classify and react to the pedestrian in time to apply the brakes.

The National Transportation Safety Board (NTSB) investigated the crash extensively. While the full chain of causation involved human distraction, vehicle design decisions, and operational policies, software behavior was a central element of the NTSB’s findings. For the DevOps and software engineering community, the incident served as a stark reminder: the code teams write can have consequences far beyond a degraded user experience or a missed sprint deadline.

Ethical Pressure Inside the Organization

The Tempe accident did not arise in a vacuum. Prior to it, Uber had already attracted significant negative attention for a range of alleged internal practices. Former software engineer Susan Fowler published a widely read account in early 2017 describing a culture of sexual harassment and management misconduct. Separately, Uber faced accusations that its engineering teams had built tools designed to exploit driver earnings, evade regulatory oversight, and deny service to passengers in ways that skirted legal boundaries.

These allegations, if accurate, represent a scenario in which software developers were asked—explicitly or implicitly—to write code in service of goals that were ethically or legally questionable. This raises an important question for every engineering organization: what happens when the people with the ability to build something are also the first line of defense against building something harmful?

What Developers Say They Would Do

Stack Overflow’s annual developer survey, which at the time of the original reporting included responses from more than 100,000 developers worldwide, offered some data on how engineers think about ethical responsibility. When asked what they would do if asked to write code for an unethical purpose:

• 58.5% said they would refuse to write it.
• 36.6% said their response would depend on the specific situation.
• 4.8% said they would write it.

On the surface, these numbers are encouraging. A strong majority of developers report a willingness to refuse unethical work. However, Stack Overflow noted a significant grey area in the findings: developers were largely uncertain about how they would report an ethical concern, and they held widely differing views about who bears ultimate responsibility when unethical code is shipped. That ambiguity is the real problem.

The Grey Area: Responsibility and Reporting

Knowing that you should refuse to write harmful code is not the same as knowing what to do next. In practice, engineers face a layered set of pressures: sprint deadlines, management directives, fear of retaliation, uncertainty about whether their concern is legitimate, and a general sense that someone higher up the chain must have already considered the implications.

This diffusion of responsibility is well-documented in organizational psychology. In software teams, it can manifest as a situation where no individual developer believes they are personally responsible for the ethical dimensions of a system, even as the system as a whole causes harm.

What DevOps Teams Can Do

Torsten Volk, an analyst at Enterprise Management Associates (EMA), argued that DevOps is uniquely positioned—and uniquely obligated—to build ethical guardrails into development culture. He identified several concrete mechanisms:

1. Full Audit Trails

Maintaining clear, immutable records of who wrote what code and when creates accountability at the individual contributor level. Volk noted that knowing an audit trail exists makes developers more likely to raise concerns with team leads before problematic code ships. Source code management systems like Git already provide the technical foundation for this; the cultural commitment to treating those records as an ethical tool is what organizations often lack.

2. Documented Ethics Discussions

When a developer flags an ethical concern, the outcome of that conversation should be documented—ideally in the same source code management or issue-tracking system the team already uses. This transforms a potentially invisible conversation into a traceable decision, and it protects the developer who raised the concern.

3. Psychological Safety for Raising Concerns

No audit trail matters if developers fear retaliation for speaking up. Organizations must actively cultivate an environment where raising an ethical red flag is treated as a professional responsibility rather than insubordination. This means leadership modeling the behavior, not just writing it into a policy document.

4. Connecting Ethics to Business Risk

Volk also argued that organizations should frame ethical coding practices in terms that resonate at the executive level: risk management and bottom-line impact. Unethical code is not just a moral failure; it is a liability. Regulatory penalties, reputational damage, and the cost of incident response all have quantifiable business consequences. Drawing a direct line between ethical engineering practices and reduced organizational risk is one of the most effective ways to secure sustained leadership buy-in.

Volk drew a parallel to GDPR compliance, suggesting that organizations could similarly recognize and publicize outstanding examples of ethical conduct in development—signaling to customers and partners that responsible engineering is a competitive differentiator, not just a cost center.

Building an Ethical Engineering Culture

The Uber case should not be read as an indictment of autonomous vehicle technology or of DevOps culture writ large. The majority of software developers, as the Stack Overflow data suggests, want to do the right thing. The challenge is structural: organizations must make it easy—and safe—for developers to act on their ethical instincts.

Practical steps for engineering leaders include:

• Adding an ethics review checkpoint to your Definition of Done or pull request template.
• Including ethical risk assessment in architecture decision records (ADRs).
• Running scenario-based ethics training as part of onboarding and continuing education.
• Establishing a clear, non-punitive escalation path for engineers who have concerns about a feature or system they are being asked to build.
• Ensuring retrospectives can surface ethical concerns, not just process inefficiencies.

Software is not neutral. The decisions made during a sprint—what a sensor system is optimized for, how an algorithm weights certain outcomes, which edge cases are treated as acceptable losses—can ripple outward in ways that affect real people. DevOps culture, with its emphasis on shared responsibility, continuous feedback, and transparency, is well suited to make ethical accountability a first-class engineering concern rather than an afterthought.