Governance, Compliance, Ethics and Sustainability

Introduction

Cloud computing changes not only how computing resources are delivered, but also how organisations make decisions about ownership, accountability, risk and social responsibility. A cloud service may be technically operated by a provider, financially purchased by a business unit, configured by an engineering team, and used to process information belonging to customers or citizens. Without clear governance, these overlapping relationships create uncertainty: resources may be unowned, data may be stored in an unsuitable jurisdiction, access may remain active after staff leave, and environmental or ethical consequences may be ignored.

Cloud governance is the system of decision rights, policies, processes, controls and evidence used to direct and control cloud adoption. Compliance is the demonstration that applicable laws, regulations, contractual requirements and recognised standards are being met. Ethics extends beyond minimum legal compliance by asking whether cloud decisions are fair, transparent, inclusive and responsible. Sustainability examines the long-term environmental, economic and social effects of computing services.

These concerns are strategic because cloud architecture affects organisational resilience, customer trust, regulatory exposure, cost, reputation and social legitimacy. Technical staff therefore need more than knowledge of virtual machines and storage. They must be able to translate organisational obligations into enforceable cloud controls and measurable outcomes.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the purpose and scope of cloud governance.
2. Design policies for resource ownership, tagging, access, data residency, auditability and risk.
3. Relate cloud operations to standards, laws and regulatory responsibilities.
4. Distinguish legal compliance from ethical cloud practice.
5. Assess accessibility, ethical sourcing, privacy and algorithmic risks.
6. Evaluate energy use, carbon impact and sustainable computing choices.
7. Apply governance principles to a realistic cloud migration scenario.

1. Cloud Governance as an Operating Model

Governance answers four basic questions:

• Who may make a decision?
• What decision or activity is permitted?
• Which evidence demonstrates that the decision was appropriate?
• What happens when policy is violated?

Management performs day-to-day planning and operation; governance establishes direction, accountability and oversight. For example, a platform team may manage identity services, but governance determines which identity controls are mandatory, who accepts residual risk, and how compliance is reviewed.

A practical cloud governance model normally includes the following domains:

Governance should be risk-based rather than merely bureaucratic. A low-risk development sandbox may need fewer controls than a production system processing health records. However, lower risk does not mean no accountability: every resource should still have an owner and a defined lifecycle.

Governance roles and accountability

Common roles include:

• Cloud governance board: sets organisational principles and resolves cross-functional issues.
• Cloud platform team: provides standard accounts, networks, identity integration and guardrails.
• Service owner: accepts responsibility for a particular application or workload.
• Data owner: determines classification, permitted use, retention and sharing.
• Data custodian: implements technical and operational protection.
• Security and privacy officers: advise on threats, controls, investigations and legal obligations.
• Finance or FinOps team: analyses consumption, forecasts expenditure and supports accountability.
• Auditors and regulators: independently evaluate control design and operation.

A RACI matrix can make responsibilities explicit: Responsible performs the work, Accountable owns the outcome, Consulted provides expertise, and Informed receives relevant information. A single control should not have several ambiguous accountable parties.

2. Resource Ownership, Tagging and Lifecycle Control

Cloud resources are easily created through portals, scripts and automated pipelines. This flexibility becomes a governance problem when resources lack owners, purpose or deletion dates. Ownership policies should require each production resource to have, at minimum, a service owner, technical owner, business unit, environment, data classification, cost centre and lifecycle status.

Tags or labels are metadata attached to resources. A tagging standard might include:

Tags are not security controls by themselves. Users may alter them, and many platform services do not inherit tags consistently. They should therefore be combined with account structure, policy enforcement, inventory scanning and periodic attestation. A policy engine can deny creation when mandatory metadata is absent, while an exception process can record justified deviations.

A resource lifecycle should normally contain request, approval, provisioning, operation, review and retirement stages. Retirement includes data retention decisions, backup deletion, credential revocation, contract closure and evidence preservation. Automated shutdown of idle development resources can reduce cost and energy use, but automation must consider backup, research and operational requirements.

3. Identity, Access and Accountability

The principle of least privilege states that a subject should receive only the permissions needed for an authorised task, for the required duration. It is implemented through role-based access control, attribute-based policies, privileged-access management, multi-factor authentication and periodic review.

Important policy rules include:

1. Use federated organisational identities instead of unmanaged personal accounts.
2. Require multi-factor authentication for privileged and remote access.
3. Prefer groups and roles to direct individual permissions.
4. Separate development, test and production privileges.
5. Use short-lived credentials and managed identities where possible.
6. Record who approved access, why it was needed and when it expires.
7. Review privileged access regularly and immediately after role changes.
8. Prohibit shared administrator accounts except under controlled emergency procedures.

Cloud responsibility is shared. The provider may secure physical facilities and core infrastructure, while the customer remains responsible for identity configuration, data permissions, operating-system settings and application security, depending on the service model. The precise division must be documented rather than assumed.

A useful access review asks whether each permission is necessary, used, approved, time-limited and consistent with separation of duties. Separation of duties prevents one person from requesting, approving and deploying a high-risk change without independent review.

4. Data Governance and Residency

Data governance concerns the full information lifecycle: creation, classification, collection, use, sharing, storage, archival and destruction. Classification schemes vary, but commonly distinguish public, internal, confidential and highly restricted information. Classification should be based on the harm caused by unauthorised disclosure, alteration, loss or unavailability.

Data residency identifies the geographic location where data is stored. Data sovereignty concerns the legal authority that may apply because data, infrastructure, provider or processing activity is connected to a jurisdiction. These concepts are related but not identical. A workload may be stored in one country, processed in another, and subject to contractual or governmental access rules involving several jurisdictions.

A residency policy should specify:

• approved regions and prohibited locations;
• whether primary data, replicas, logs and backups are included;
• permitted cross-border transfers and transfer mechanisms;
• provider notification obligations;
• encryption and key-management requirements;
• retention and deletion expectations;
• procedures for legal requests and government access.

Encryption protects confidentiality but does not automatically resolve residency or sovereignty concerns. Metadata, diagnostic logs and support tickets may also contain personal or sensitive information. A complete data-flow map is therefore more useful than checking only the primary database location.

Privacy principles generally include purpose limitation, data minimisation, transparency, accuracy, retention limitation, security and accountability. The exact legal requirements depend on jurisdiction and sector. For example, personal-data protection law, health regulation, financial regulation, education law and public-sector requirements may impose different obligations. Organisations should obtain qualified legal advice rather than treating a general cloud checklist as legal compliance.

5. Auditability, Monitoring and Evidence

Auditability is the ability to reconstruct what happened, who acted, which policy applied and whether the action was authorised. It requires more than collecting logs. Evidence must be complete enough, protected from unauthorised alteration, retained for an appropriate period and understandable to an independent reviewer.

A cloud audit programme should address:

• identity and authentication events;
• administrative API calls;
• configuration changes;
• network and application events;
• data access where appropriate;
• deployment records;
• vulnerability and patch status;
• backup and recovery tests;
• policy violations and exceptions;
• incident response actions.

Logs should be sent to a controlled, central destination with restricted write access, time synchronisation and integrity protection. Retention must balance legal requirements, investigative value, storage cost and privacy. Excessive logging can itself create a sensitive data store.

A control is stronger when it produces repeatable evidence. For example, a statement that “production access is reviewed quarterly” is weaker than an automated report showing the reviewer, date, accounts examined, findings and remediation status. Evidence should demonstrate both control design and control operation.

6. Standards, Regulations and Risk Management

Standards are generally voluntary frameworks or specifications, while regulations are legally enforceable requirements. Contracts may impose obligations that are not directly required by law. Organisations often use standards to structure their control environment and then map those controls to laws, contracts and internal policies.

Relevant examples include:

• ISO/IEC 27001: information-security management systems.
• ISO/IEC 27017: cloud-specific information-security controls.
• ISO/IEC 27018: protection of personally identifiable information in public clouds.
• ISO/IEC 27701: privacy information management.
• NIST Cybersecurity Framework: functions for identifying, protecting, detecting, responding and recovering.
• NIST SP 800-53: extensive security and privacy controls, especially in government contexts.
• SOC reports: independent examinations of service-provider controls, with scope and assurance type requiring careful interpretation.
• CIS Controls and benchmarks: prioritised safeguards and secure configuration guidance.

A certification or provider attestation is not a guarantee that a customer workload is compliant. Scope, service boundaries, dates, exceptions and customer responsibilities must be examined. A customer may inherit some provider controls but must configure and operate its own controls correctly.

Risk management identifies threats, vulnerabilities, impacts and likelihoods, then selects treatments. A qualitative matrix may classify risk as low, medium or high. Quantitative analysis can estimate expected annual loss:

Here, ALE is annualised loss expectancy, SLE is single-loss expectancy measured in currency, and ARO is annual rate of occurrence. The model assumes that loss events can be represented reasonably by an estimated frequency and impact. It is a decision aid, not a prediction, and it may be unreliable when data are scarce or impacts are non-financial.

For example, if a severe configuration exposure could cost $120,000 and is estimated to occur 0.2 times per year, then ALE = $120,000 × 0.2 = $24,000 per year. A control costing $8,000 annually may be economically attractive, but non-financial effects such as safety, legal penalties and reputation must also be considered.

Risk treatment options are avoid, reduce, transfer and accept. Acceptance must be explicit, assigned to an authorised risk owner, time-limited where possible and supported by compensating controls.

7. Ethics, Fairness and Human Responsibility

Legal compliance is a minimum threshold. Ethical cloud practice asks whether a decision respects human dignity and avoids foreseeable harm even when the law is silent or enforcement is weak.

Privacy and surveillance

Cloud analytics can combine large datasets to infer behaviour, location, health or financial status. Ethical practice requires necessity, proportionality, transparency and meaningful consent where consent is the appropriate basis. “Anonymous” data should not be assumed safe without considering re-identification risks. Access to sensitive analytics should be restricted, monitored and periodically justified.

Artificial intelligence and automated decisions

Cloud platforms make machine-learning services widely available. Risks include biased training data, proxy discrimination, opaque decisions, insecure models, data leakage and automation bias. Organisations should document the purpose and limits of an AI system, evaluate performance across relevant groups, retain human oversight for consequential decisions, protect training data and provide mechanisms for explanation, appeal and correction.

Ethical sourcing and labour

Cloud supply chains include data-centre construction, semiconductor production, networking equipment, software labour, minerals and outsourced support. Ethical procurement considers forced labour, worker safety, fair pay, freedom of association, conflict minerals, environmental pollution and supplier transparency. A low price does not demonstrate responsible sourcing. Supplier codes of conduct should be supported by due diligence, contractual requirements, credible audits and remediation processes.

Accessibility and inclusion

Cloud-hosted applications should be usable by people with diverse sensory, motor, cognitive and linguistic abilities. Accessibility includes keyboard operation, screen-reader compatibility, sufficient colour contrast, captions, clear language, adaptable layouts and accessible authentication. Accessibility should be tested with users and integrated into procurement, design and acceptance criteria rather than added after deployment.

8. Sustainable Computing

Sustainable computing seeks to deliver required services while reducing environmental harm and preserving long-term economic and social capacity. Relevant impacts include electricity consumption, greenhouse-gas emissions, water use, hardware extraction, electronic waste and local community effects.

A common data-centre efficiency metric is power usage effectiveness:

Both quantities must be measured over the same period and in the same energy unit, such as kilowatt-hours. PUE is at least 1 in the usual definition; a value closer to 1 indicates that a smaller proportion of energy is used by cooling, lighting and other overheads. PUE does not measure the carbon intensity of electricity, embodied emissions of hardware, or the usefulness of the computing work.

Operational electricity emissions may be estimated as:

Energy is measured in kilowatt-hours, the emission factor in kilograms of carbon-dioxide equivalent per kilowatt-hour, and the result in kilograms of CO₂e. The estimate depends on whether the factor is location-based or market-based and on the quality and time period of the data.

For example, a workload using 10,000 kWh with an emission factor of 0.35 kg CO₂e/kWh produces approximately 3,500 kg CO₂e, or 3.5 metric tonnes. This excludes embodied emissions unless they are separately estimated. Carbon offsets should not be used to excuse avoidable energy consumption or weak efficiency practices.

Sustainable cloud practices include right-sizing resources, shutting down idle environments, selecting efficient architectures, improving utilisation, using managed services carefully, choosing lower-carbon regions when residency permits, extending hardware life, reducing data duplication and designing retention policies that delete unnecessary data. Serverless and managed services may improve utilisation, but they are not automatically sustainable; measurement is necessary.

Sustainability decisions involve trade-offs. Replication improves resilience but consumes additional storage and energy. Strong encryption may increase processing overhead, while insufficient protection creates unacceptable risk. A responsible design evaluates service level, security, legal requirements, carbon, water and cost together.

Figure: Governance is a continuous cycle rather than a one-time approval.

9. Applied Case: Northstar Health Migration

Background

Northstar Health, an illustrative regional healthcare provider, plans to migrate its appointment, billing and clinical reporting systems to a public cloud. The provider operates across two countries and uses external laboratories. Its data includes personal identifiers, payment information and sensitive health records.

Problem

An initial pilot placed databases, backups and diagnostic logs in different regions. Several engineers used permanent administrator accounts, project resources had inconsistent tags, and the organisation could not produce a complete record of who accessed clinical reports. The migration team focused on availability and cost but had not documented residency, retention or supplier responsibilities.

Analysis

The governance board classified clinical records as highly restricted and identified confidentiality, integrity, availability and lawful processing as material risks. A data-flow assessment showed that logs contained patient identifiers. The team also discovered that a laboratory integration contract required notification before cross-border processing.

Approach and solution

Northstar established a service owner and data owner for each workload. A landing zone enforced separate production and non-production accounts, federated identity, multi-factor authentication, private networking and central logging. Policy-as-code required owner, data-classification, cost-centre and expiry tags. Production access became time-limited and approval-based.

The organisation selected approved regions, restricted backup replication, and configured log redaction. It created a retention schedule for clinical records, audit logs and backups. A supplier register recorded provider attestations, subcontractors, incident-notification terms and exit procedures. Quarterly access reviews and annual recovery exercises became mandatory evidence.

Sustainability was included in architecture review. Non-production systems were stopped outside working hours, storage tiers were matched to access patterns, and the team selected a lower-carbon region where legal and latency requirements allowed. These measures were evaluated alongside clinical availability requirements rather than treated as a separate technical project.

Outcome

Northstar gained a defensible record of ownership, data location, access decisions and control operation. The migration took longer than the original schedule, but the organisation reduced unmanaged privileges, eliminated unauthorised replication and improved incident investigation. The case also demonstrated that governance must begin during architecture and procurement, not after deployment.

Learning points

1. Sensitive data includes copies, logs and metadata, not only primary databases.
2. Provider certifications do not replace customer controls.
3. Automated guardrails are more reliable than policy documents alone.
4. Sustainability, privacy and resilience involve genuine design trade-offs.
5. Evidence must be designed into operations from the beginning.

10. Implementation Guidance and Contemporary Developments

A practical implementation sequence is:

1. Identify business services, data types, jurisdictions and risk owners.
2. Define mandatory controls and a documented exception process.
3. Build standard cloud landing zones with identity, networking, logging and policy guardrails.
4. Establish an asset inventory and enforce ownership metadata.
5. Map controls to laws, contracts and selected standards.
6. Automate compliance checks and route findings to accountable owners.
7. Measure access, incidents, recovery, cost, energy and emissions.
8. Test controls through reviews, exercises and independent assurance.
9. Retire unused resources and update policies as technology and law change.

Contemporary governance increasingly uses policy-as-code, continuous control monitoring, confidential computing, software supply-chain attestations and automated data discovery. Generative AI can assist with policy analysis, evidence classification and anomaly detection, but it introduces risks involving inaccurate recommendations, confidential prompts, biased decisions and unclear accountability. AI-generated compliance conclusions must be reviewed by qualified humans and supported by authoritative evidence.

Major limitations remain. Cloud provider transparency may be incomplete; emissions estimates may use different boundaries; laws differ across jurisdictions; and control automation can create false assurance when underlying data are inaccurate. Governance should therefore combine automation with independent challenge, human judgement and periodic reassessment.

Chapter Summary

Cloud governance establishes decision rights, ownership, policy, controls and evidence for cloud services. Effective governance covers resource tagging and lifecycle, identity and least privilege, data classification and residency, auditability, risk treatment, supplier accountability and continuous improvement. Standards such as ISO/IEC 27001 and NIST frameworks provide useful control structures, but certification does not transfer all responsibility from the customer.

Compliance involves laws, regulations, contracts and evidence; ethics goes further by addressing privacy, fairness, accessibility, human welfare and responsible sourcing. Sustainability requires measurement of energy, carbon, water, hardware and electronic waste. Metrics such as PUE and operational CO₂e estimates are useful but incomplete. The strongest cloud operating models integrate governance, security, privacy, compliance, sustainability and business objectives throughout the service lifecycle.

Key Terms

Cloud governance: The system of decision rights, policies, controls and oversight used to direct cloud use.

Shared responsibility: The division of security and operational duties between a cloud provider and its customer.

Resource owner: The person or team accountable for a cloud resource or service.

Tagging: Attaching metadata to resources for ownership, classification, cost and lifecycle purposes.

Least privilege: Giving a subject only the access necessary for an authorised task.

Separation of duties: Dividing sensitive activities among different people or roles.

Data classification: Categorising information according to sensitivity and required protection.

Data residency: The geographic location where data is stored or processed.

Data sovereignty: The legal authority and jurisdictional obligations associated with data.

Auditability: The ability to reconstruct actions, decisions and control operation from evidence.

Policy-as-code: Expressing governance or security rules in machine-enforceable form.

Compliance: Conformance with applicable laws, regulations, contracts and standards.

Risk owner: The authorised person accountable for accepting or treating a risk.

Residual risk: Risk remaining after controls have been applied.

Ethical sourcing: Procuring technology while considering labour, human-rights and environmental impacts.

Accessibility: Designing services so people with diverse abilities can use them effectively.

PUE: Power usage effectiveness, calculated as total facility energy divided by IT equipment energy.

CO₂e: Carbon-dioxide equivalent, a common unit for comparing greenhouse-gas impacts.

Embodied emissions: Emissions associated with producing, transporting and disposing of equipment.

Sustainable computing: Delivering computing services while reducing environmental and social harm.

Review Questions

5 Short Answer Questions

1. What is the difference between cloud governance and cloud management?
2. Why are tags useful, and why should they not be treated as the only governance control?
3. Explain the difference between data residency and data sovereignty.
4. What does least privilege require?
5. What does PUE measure?

5 Long Answer Questions

1. Design a governance structure for a university migrating student and research systems to a public cloud.
2. Explain how identity, logging, evidence retention and access reviews support auditability.
3. Compare standards, regulations, contracts and provider attestations as sources of cloud obligations.
4. Discuss the ethical responsibilities associated with cloud-hosted artificial intelligence.
5. Explain why sustainability cannot be evaluated using electricity consumption alone.

3 Analytical / Application Questions

1. An organisation discovers that production databases are in an approved region but backups and support logs are elsewhere. Analyse the risks and propose a remediation plan.
2. A team proposes deleting all non-production resources every Friday to reduce cost and energy use. Evaluate the proposal, including governance, recovery, research and sustainability considerations.
3. A cloud workload uses 18,000 kWh annually and the applicable emission factor is 0.42 kg CO₂e/kWh. Calculate operational emissions and explain at least three limitations of the estimate.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily a governance function?

A. Choosing a programming language for an application

B. Defining who may accept residual cloud risk

C. Increasing the CPU size of a virtual machine

D. Writing a unit test

Correct Answer: B. Defining who may accept residual cloud risk

Question 2

Which tag most directly supports financial accountability?

A. CostCentre

B. ScreenColour

C. KeyboardType

D. BrowserVersion

Correct Answer: A. CostCentre

Question 3

What is the main purpose of least privilege?

A. To maximise the number of administrators

B. To provide permanent access to all engineers

C. To limit permissions to those necessary for authorised tasks

D. To eliminate the need for authentication

Correct Answer: C. To limit permissions to those necessary for authorised tasks

Question 4

Which statement about provider certification is correct?

A. It guarantees that every customer workload is compliant

B. It replaces the customer’s access-control responsibilities

C. It is irrelevant to assurance activities

D. Its scope and customer responsibilities must be examined

Correct Answer: D. Its scope and customer responsibilities must be examined

Question 5

Which item may be overlooked when assessing data residency?

A. Office furniture

B. Diagnostic logs and backups

C. Employee uniforms

D. Application colour schemes

Correct Answer: B. Diagnostic logs and backups

Question 6

What does auditability require?

A. Only storing monthly invoices

B. Deleting all administrative records quickly

C. Being able to reconstruct authorised actions from reliable evidence

D. Allowing shared administrator accounts

Correct Answer: C. Being able to reconstruct authorised actions from reliable evidence

Question 7

If total facility energy is 1,200 kWh and IT equipment energy is 800 kWh, what is the PUE?

A. 0.67

B. 1.5

C. 2.0

D. 2.5

Correct Answer: B. 1.5

Question 8

A workload uses 5,000 kWh with an emission factor of 0.4 kg CO₂e/kWh. What operational emission estimate results?

A. 200 kg CO₂e

B. 1,250 kg CO₂e

C. 2,000 kg CO₂e

D. 5,400 kg CO₂e

Correct Answer: C. 2,000 kg CO₂e

Question 9

Which practice best reflects ethical accessibility?

A. Testing only with the development team

B. Providing accessibility requirements and testing with users who have diverse abilities

C. Removing captions to reduce storage use

D. Requiring mouse-only navigation

Correct Answer: B. Providing accessibility requirements and testing with users who have diverse abilities

Question 10

Which is a responsible risk-treatment approach?

A. Accepting every risk automatically

B. Ignoring non-financial impacts

C. Assigning explicit acceptance to an authorised risk owner

D. Hiding exceptions from auditors

Correct Answer: C. Assigning explicit acceptance to an authorised risk owner