Governance, Risk, Compliance, Ethics, and Legal Requirements

Introduction

Cloud computing changes not only where information is processed but also who controls infrastructure, how evidence is collected, and how legal responsibility is distributed. A cloud customer may own the data and determine its purpose, while a cloud service provider operates the physical facilities, hypervisors, networks, and managed services. This division creates a shared-responsibility environment in which security failures can result from technical weaknesses, unclear contracts, poor governance, unlawful processing, or unethical decisions.

Cloud security governance is the system by which an organisation directs, controls, and evaluates the protection of cloud services. Risk management identifies uncertainty that could affect organisational objectives and determines how that uncertainty should be treated. Compliance establishes obligations arising from laws, regulations, contracts, standards, and internal policies. Ethics addresses what responsible professionals ought to do, including situations in which legal compliance is insufficient.

This chapter explains how NIST, ISO/IEC 27001, the Cloud Security Alliance Cloud Controls Matrix (CSA CCM), and the CIS Controls can be used together. It also examines privacy, data sovereignty, contracts, professional ethics, regulatory duties, and practical assurance activities.

Learning Objectives

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

1. Explain the relationship between governance, risk, compliance, and ethics in cloud environments.
2. Apply the NIST Cybersecurity Framework, NIST risk-management concepts, ISO/IEC 27001, CSA CCM, and CIS Controls to cloud-security decisions.
3. Identify privacy, sovereignty, contractual, regulatory, and supply-chain obligations.
4. Construct a basic cloud risk register and select proportionate treatments.
5. Evaluate cloud contracts, evidence, audit rights, and shared-responsibility arrangements.
6. Analyse an applied cloud-governance scenario and justify professional decisions.

Governance in the Cloud

Governance converts organisational objectives into authority, policies, accountability, and measurable controls. Effective governance answers five questions:

• What assets and services are important?
• Who is accountable for them?
• Which risks are acceptable?
• Which obligations apply?
• How will performance and compliance be demonstrated?

Governance is broader than security administration. A security team may configure identity controls, but the board or executive leadership normally determines risk appetite. A data owner classifies information and approves access, while a system owner implements controls. Procurement, legal, privacy, audit, and business continuity functions also contribute.

The shared-responsibility model

In an infrastructure-as-a-service model, the provider commonly manages facilities, physical hardware, and core virtualization, while the customer manages operating systems, applications, identities, configurations, and data. In platform-as-a-service, the provider manages more of the operating environment, but the customer remains responsible for application logic, data, identities, and appropriate configuration. In software-as-a-service, the provider operates most technical components, but the customer still controls users, permissions, data use, retention, and contractual oversight.

The exact boundary is service-specific and must not be assumed from a generic diagram. It should be documented in the provider's service description, responsibility matrix, contract, and operating procedures. A control that is “provided by the cloud” is not necessarily enabled, correctly configured, or suitable for the customer's legal obligations.

Governance instruments

Important governance instruments include:

• a cloud strategy and approved-service catalogue;
• information-classification and data-retention policies;
• risk appetite and risk-acceptance criteria;
• identity, encryption, logging, and incident-response standards;
• supplier due-diligence and continuous-monitoring procedures;
• architecture review and change-management processes;
• documented roles, escalation paths, and exception procedures;
• audit, metrics, and management-review arrangements.

Governance should be risk-based rather than compliance-only. A certificate may provide useful evidence, but it does not prove that a specific workload is securely designed or lawfully processed.

Risk Management for Cloud Services

Risk is commonly described as the effect of uncertainty on objectives. In security practice, a risk scenario connects an asset or business process, a threat, a vulnerability, an event, and an impact. For example, excessive administrator permissions may allow an attacker using a stolen credential to alter customer records, causing regulatory, financial, and reputational harm.

A qualitative risk model can use:

Likelihood and impact may be ranked, for example, from 1 to 5. This is a prioritisation aid, not a physical law. Scores are ordinal unless the organisation has carefully defined quantitative meanings; multiplying ranks does not produce a probability or monetary loss.

A quantitative expected-loss model is sometimes used:

Here, ALE is annualised loss expectancy in currency per year, SLE is single-loss expectancy in currency per event, and ARO is annual rate of occurrence in events per year. The model assumes that loss events and estimates are sufficiently defined and that the average frequency is meaningful. It can mislead when data is scarce, impacts are nonlinear, or catastrophic events are difficult to estimate.

Risk-management process

A practical process consists of:

1. Establish context. Identify business objectives, stakeholders, legal jurisdictions, risk appetite, and dependencies.
2. Identify assets and data. Record applications, services, identities, keys, records, interfaces, and providers.
3. Identify threats and vulnerabilities. Consider misconfiguration, credential theft, insider misuse, insecure APIs, provider outage, supply-chain compromise, and unlawful processing.
4. Analyse likelihood and impact. Consider confidentiality, integrity, availability, privacy, safety, financial loss, and legal consequences.
5. Evaluate and prioritise. Compare results with risk criteria and determine whether treatment is required.
6. Treat the risk. Avoid, reduce, transfer, share, or accept it. “Transfer” through insurance or a contract does not eliminate the underlying harm.
7. Monitor and communicate. Reassess after changes, incidents, new threats, or changes in law.

Risk acceptance must be explicit, time-limited where appropriate, assigned to an authorised risk owner, and supported by compensating controls or a remediation plan. Security personnel should not silently accept business risk on behalf of executives.

Major Frameworks and How They Fit Together

NIST Cybersecurity Framework

The NIST Cybersecurity Framework 2.0 organises cybersecurity outcomes into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. Govern establishes strategy, roles, policy, oversight, and supply-chain expectations. Identify develops knowledge of assets, risks, and dependencies. Protect implements safeguards such as identity management and data security. Detect identifies anomalous activity. Respond contains and manages incidents. Recover restores services and improves resilience.

The framework is outcome-oriented. It does not prescribe one product or architecture. Organisations can create a current profile describing present outcomes and a target profile describing desired outcomes, then analyse the gap and prioritise actions.

NIST SP 800-37 describes a Risk Management Framework with steps including prepare, categorise, select, implement, assess, authorise, and monitor. NIST SP 800-53 provides a catalogue of security and privacy controls. These publications are especially useful when an organisation needs structured control selection and authorisation evidence.

ISO/IEC 27001

ISO/IEC 27001 specifies requirements for an information security management system (ISMS). An ISMS is a management system, not merely a technical control list. It requires context, leadership, planning, risk assessment, risk treatment, documented information, competence, operation, performance evaluation, and continual improvement.

The organisation defines the ISMS scope, assesses risks, selects treatments, and documents applicability. The Statement of Applicability explains which controls are included or excluded and why. ISO/IEC 27001 certification is granted to an organisation within a defined scope by an independent certification body; it is not a universal guarantee that every service or workload is secure.

ISO/IEC 27017 provides cloud-specific guidance for information-security controls, and ISO/IEC 27018 addresses protection of personally identifiable information in public clouds acting as processors. These complements can help interpret cloud roles but must be read alongside applicable law and contracts.

CSA Cloud Controls Matrix

The CSA CCM is a cloud-focused control framework organised into domains such as governance, risk and compliance, identity and access management, data security, application and interface security, logging and monitoring, infrastructure and virtualization security, and supply-chain management. It is valuable for evaluating provider capabilities and mapping cloud-specific responsibilities.

The CSA questionnaire and related assurance materials can support procurement and due diligence. However, an organisation must validate the scope, date, service boundaries, exceptions, and independent evidence rather than treating a completed questionnaire as proof of effectiveness.

CIS Controls

The CIS Controls are prioritised safeguards intended to reduce common attack paths. They include enterprise asset inventory, software inventory, data protection, secure configuration, account management, access control, vulnerability management, audit-log management, email and browser protections, malware defenses, recovery, security awareness, and service-provider management.

They are operationally useful because they translate governance goals into implementable practices. For example, a cloud programme can begin with an accurate inventory of accounts, subscriptions, assets, workloads, and external services; enforce secure configurations through policy-as-code; centralise logs; and test recovery.

Using frameworks together

Frameworks should be mapped, not mechanically stacked. NIST can provide an organising lifecycle; ISO/IEC 27001 can provide management-system discipline; CSA CCM can provide cloud-specific control language; and CIS Controls can provide prioritised technical safeguards. A crosswalk reduces duplicated evidence, but it does not remove the need to understand each framework's purpose.

Privacy, Data Sovereignty, and Legal Requirements

Privacy concerns the rights and interests of identifiable individuals and the lawful, fair, and transparent handling of their information. Common principles include purpose limitation, data minimisation, accuracy, storage limitation, security, accountability, and transparency. Specific obligations vary by jurisdiction. Examples include the EU General Data Protection Regulation (GDPR), the California Consumer Privacy Act and related California legislation, sectoral health or financial laws, and national data-protection statutes.

Organisations should distinguish:

• controller or business: determines purposes and means of processing;
• processor or service provider: processes information on behalf of another organisation;
• data subject or consumer: the individual to whom personal data relates;
• subprocessor: a provider engaged by a processor to handle data.

A cloud contract should specify processing purposes, categories of data, instructions, confidentiality, security measures, subprocessors, assistance with individual rights, breach notification, deletion or return, audit evidence, and international-transfer mechanisms where relevant. A privacy impact assessment or data-protection impact assessment may be required for high-risk processing.

Data sovereignty is a broad term that may refer to the law of the place where data is stored, processed, or accessed; the authority of a jurisdiction over the organisation; or a policy requiring data to remain in a specified territory. Data residency is narrower: it concerns physical or logical location. Residency does not necessarily prevent foreign administrative access, support access, replication, or legal compulsion. Therefore, location claims must be tested against service architecture, backup regions, support operations, encryption-key management, and subcontractors.

Legal compliance may also involve records management, e-discovery, intellectual property, export controls, accessibility, breach reporting, financial controls, and sector-specific requirements. The correct legal interpretation depends on facts and jurisdiction; security professionals should involve qualified legal and privacy specialists rather than presenting general guidance as legal advice.

Contracts and Third-Party Assurance

A cloud contract is a security control. Important provisions include:

• clearly defined services, service levels, and responsibility boundaries;
• security requirements and minimum control baselines;
• data ownership, permitted use, retention, deletion, and portability;
• incident notification timing, cooperation, and forensic access;
• subcontractor disclosure and objection rights;
• location, transfer, and government-access provisions;
• audit rights, independent assurance reports, and remediation duties;
• availability, recovery objectives, maintenance, and exit assistance;
• liability, indemnity, insurance, and limitation-of-liability terms;
• termination, data return, verified deletion, and transition support.

Service-level agreements should not be confused with security guarantees. An availability percentage may define service credits without compensating for confidentiality loss. Contracts should also address evidence: logging retention, access to relevant records, vulnerability-notification processes, penetration-testing rules, and the provider's obligation to preserve evidence.

Third-party risk is continuous. Review provider changes, new subprocessors, mergers, incidents, control reports, geopolitical developments, and service deprecations. A provider with excellent infrastructure can still create unacceptable concentration, lock-in, or jurisdictional risk.

Ethics and Professional Responsibility

Ethical security practice goes beyond minimum legal compliance. Professionals should protect confidentiality, avoid unnecessary collection, respect autonomy, preserve evidence, disclose conflicts of interest, and use authority only for authorised purposes. The principles of beneficence, non-maleficence, justice, autonomy, and accountability provide useful ethical lenses.

Examples of ethical questions include:

• Is it proportionate to retain detailed employee activity logs indefinitely?
• Should an organisation deploy facial recognition merely because it is technically possible?
• Is a vulnerability report being delayed to protect reputation?
• Are automated decisions explainable and contestable?
• Does a low-cost cloud region expose individuals to unacceptable legal or social risk?

Security monitoring can protect systems but can also become invasive surveillance. Artificial intelligence may improve anomaly detection and policy analysis, yet it can produce false positives, reveal sensitive data to external models, or automate discriminatory decisions. Governance should require approved use cases, data minimisation, human review, testing, model access controls, logging, and mechanisms for appeal. AI-generated configuration or compliance evidence must be independently reviewed.

Professional codes, such as those associated with computing and security bodies, commonly emphasise public welfare, competence, honesty, privacy, and avoidance of harm. When instructions conflict with law, policy, or public safety, professionals should document concerns, use escalation channels, and seek independent advice.

Applied Case: Northstar Health Analytics

This is an illustrative fictional case. Northstar Health Analytics is a university-affiliated company that stores de-identified and identifiable clinical research data in a public cloud. It plans to use a managed analytics platform operated across several regions. Researchers want rapid access, executives want low cost, and the provider advertises ISO/IEC 27001 certification and strong availability.

Background and problem

The initial design permits researchers to create storage buckets, uses a global identity administrator account for convenience, and copies backups to a second region without documenting its legal status. The contract contains an availability service level but is vague about deletion, subprocessors, forensic cooperation, and breach notification. A privacy officer is concerned that the data may be re-identifiable when combined with genomic attributes.

Analysis

The data inventory shows identifiable health information, pseudonymised research data, credentials, logs, and model outputs. Threats include credential compromise, accidental public exposure, insider misuse, ransomware, provider outage, and re-identification. Applicable requirements may include data-protection law, research ethics approval, contractual confidentiality, and health-sector rules. The provider certificate is useful but does not establish that Northstar's tenant configuration or cross-region backups satisfy these requirements.

The risk register prioritises excessive privileges, uncontrolled replication, and inadequate exit capability. Each risk is assigned an owner. The privacy assessment identifies data minimisation, retention, access transparency, and international-transfer questions.

Approach and solution

Northstar adopts a NIST-based target profile and uses ISO/IEC 27001 risk and review practices. CSA CCM is used to question the provider about data security, portability, logging, and shared responsibilities. CIS Controls guide implementation of asset inventory, secure configuration, account management, vulnerability management, logging, and recovery.

The technical design introduces separate accounts and environments, phishing-resistant multifactor authentication, least-privilege roles, approval for privileged access, encryption in transit and at rest, customer-controlled keys where feasible, private service endpoints, immutable backups, centralised logging, and automated configuration checks. Data is classified and replicated only to approved regions. Researchers receive tokenised datasets by default, while exceptional access requires documented approval.

The revised contract identifies processing roles, approved subprocessors and locations, notification duties, evidence access, deletion verification, recovery expectations, portability formats, and termination assistance. A tabletop exercise tests a compromised administrator, a provider outage, and a suspected data breach.

Outcome and learning points

Northstar accepts a limited residual risk for a research workload after documenting safeguards and executive approval. It rejects the global replication feature until legal and privacy questions are resolved. The case demonstrates that governance is not a paperwork layer added after deployment. It shapes architecture, procurement, identity management, data lifecycle, monitoring, and exit planning.

Implementation Guidance and Limitations

A practical cloud-governance programme should begin with a complete service and data inventory. It should then establish classification, approved patterns, baseline configurations, identity standards, logging requirements, vulnerability management, backup testing, incident procedures, and supplier review. Controls should be automated where reliable—for example, policy checks can detect public storage or unapproved regions—but automation requires exception handling and human oversight.

Evidence should be specific and current: architecture diagrams, access reviews, configuration records, risk decisions, incident exercises, provider reports, contract schedules, deletion certificates, and management-review minutes. Metrics should support decisions rather than reward superficial activity. Useful measures include the percentage of inventoried assets, age of critical vulnerabilities, privileged-account review completion, log coverage, recovery-test success, unresolved high-risk exceptions, and time to revoke access.

Framework limitations must be recognised. No framework predicts every threat. Crosswalks can create false confidence when control meanings differ. Certification has scope and time boundaries. Quantitative risk estimates may be uncertain. Legal requirements change and can conflict across jurisdictions. Cloud services evolve rapidly, and a secure design can become unsafe after a feature, region, identity policy, or subcontractor changes.

Chapter Summary

Cloud governance establishes direction, accountability, risk appetite, and oversight across a shared-responsibility environment. Risk management identifies threats and impacts, selects proportionate treatments, assigns ownership, and monitors residual risk. The NIST Cybersecurity Framework provides an outcome-oriented lifecycle; NIST risk-management publications support categorisation, control selection, authorisation, and monitoring. ISO/IEC 27001 provides an auditable information-security management system, while CSA CCM supplies cloud-specific control perspectives and CIS Controls prioritise practical safeguards.

Privacy, data sovereignty, contracts, and professional ethics are inseparable from cloud security. Data location does not by itself determine legal exposure, and provider certification does not replace customer responsibility. Effective programmes combine technical safeguards, privacy assessments, contractual controls, independent evidence, continuous supplier monitoring, and ethical judgement. The strongest cloud-security decisions are documented, proportionate, reviewable, and aligned with both organisational objectives and the rights of affected people.

Key Terms

Governance: Direction, accountability, oversight, and decision-making for organisational objectives.

Risk appetite: The amount and type of risk an organisation is willing to pursue or retain.

Risk owner: The person accountable for managing or accepting a specified risk.

Shared responsibility: Division of security duties between a cloud provider and customer.

ISMS: Information security management system used to direct and improve security activities.

NIST CSF: A framework organised around Govern, Identify, Protect, Detect, Respond, and Recover.

ISO/IEC 27001: International standard specifying requirements for an information-security management system.

CSA CCM: Cloud Security Alliance matrix of cloud-specific security controls.

CIS Controls: Prioritised safeguards for reducing common cybersecurity risks.

Privacy: Responsible and lawful handling of information relating to identifiable individuals.

Controller: Entity determining purposes and means of personal-data processing.

Processor: Entity processing personal data on behalf of a controller.

Data sovereignty: Jurisdictional authority and legal control associated with data and processing.

Data residency: Physical or logical location where data is stored or processed.

Due diligence: Investigation of a provider's capability, controls, risks, and obligations.

Residual risk: Risk remaining after controls and treatments are applied.

Compensating control: Alternative safeguard used when a preferred control is impractical.

Statement of Applicability: ISO/IEC 27001 document explaining selected and excluded controls.

Privacy impact assessment: Structured analysis of privacy risks and mitigations.

Audit evidence: Reliable records demonstrating that controls or obligations are addressed.

Review Questions

Short Answer Questions

1. What is meant by the cloud shared-responsibility model?
2. Distinguish data residency from data sovereignty.
3. What purpose does an ISO/IEC 27001 Statement of Applicability serve?
4. Why should risk acceptance be assigned to an authorised risk owner?
5. Name three provisions that should appear in a cloud-security contract.

Long Answer Questions

1. Compare the roles of NIST CSF, ISO/IEC 27001, CSA CCM, and CIS Controls in a cloud-security programme.
2. Explain a complete cloud risk-management process, from context establishment through monitoring.
3. Discuss why a cloud-provider certification cannot by itself demonstrate legal compliance or secure customer configuration.
4. Analyse the relationship between privacy, data minimisation, retention, and cloud backup design.
5. Explain how ethical reasoning can alter a technically legal cloud-monitoring or artificial-intelligence deployment.

Analytical / Application Questions

1. A company wants to store employee health data in a provider's “global” region. Construct the key questions that governance, privacy, legal, procurement, and technical teams should resolve before approval.
2. A cloud audit finds that 20% of storage resources are not inventoried and several administrators share one account. Identify the principal risks, propose treatments using at least two frameworks, and specify evidence that management should review.
3. A provider refuses customer penetration testing but supplies an independent assurance report. Evaluate whether the report is sufficient and propose contractual and technical compensating measures.

Multiple Choice Questions with Answers

Question 1

Which NIST Cybersecurity Framework function establishes cybersecurity strategy, roles, policy, and oversight?

A. Govern

B. Protect

C. Detect

D. Recover

Correct Answer: A. Govern

Question 2

In the cloud shared-responsibility model, which activity normally remains a customer responsibility even in software as a service?

A. Operating the provider’s physical data centre

B. Managing customer users and access permissions

C. Replacing failed provider disks

D. Maintaining the provider’s hypervisor

Correct Answer: B. Managing customer users and access permissions

Question 3

What does the ISO/IEC 27001 Statement of Applicability primarily explain?

A. The provider’s monthly availability percentage

B. The organisation’s selected and excluded controls and their justification

C. The number of cloud users in each department

D. The encryption algorithm used by every supplier

Correct Answer: B. The organisation’s selected and excluded controls and their justification

Question 4

Which statement best distinguishes data residency from data sovereignty?

A. Residency concerns location, while sovereignty concerns applicable jurisdiction and legal authority

B. Residency concerns encryption, while sovereignty concerns availability

C. Residency applies only to paper records, while sovereignty applies only to databases

D. There is no meaningful distinction between the terms

Correct Answer: A. Residency concerns location, while sovereignty concerns applicable jurisdiction and legal authority

Question 5

A risk register rates likelihood as 4 and impact as 5 on defined ordinal scales. Using Risk score = Likelihood × Impact, what is the score?

A. 9

B. 20

C. 25

D. 45

Correct Answer: B. 20

Question 6

Which framework is specifically designed as a cloud-focused control matrix?

A. CSA Cloud Controls Matrix

B. CIS Controls only

C. NIST Privacy Framework only

D. An organisation’s service-level agreement

Correct Answer: A. CSA Cloud Controls Matrix

Question 7

Why is a provider’s ISO/IEC 27001 certification insufficient by itself for a customer’s compliance decision?

A. ISO/IEC 27001 prohibits cloud computing

B. Certification has a defined scope and does not prove the customer’s configuration or legal compliance

C. Certification applies only to physical security guards

D. Certification automatically transfers all customer liability to the provider

Correct Answer: B. Certification has a defined scope and does not prove the customer’s configuration or legal compliance

Question 8

Which contract provision most directly supports a controlled end-of-service transition?

A. Marketing approval rights

B. Data return, verified deletion, portability, and transition assistance

C. A larger provider logo in the contract

D. A promise that all future services will be free

Correct Answer: B. Data return, verified deletion, portability, and transition assistance

Question 9

Which is an ethical concern associated with security monitoring?

A. Whether monitoring is proportionate and respects privacy

B. Whether the organisation has enough office furniture

C. Whether a service has a graphical dashboard

D. Whether a provider offers a trial account

Correct Answer: A. Whether monitoring is proportionate and respects privacy

Question 10

Which CIS Control activity most directly helps an organisation discover unknown cloud resources?

A. Enterprise asset inventory

B. Public relations planning

C. Contract translation

D. Office attendance tracking

Correct Answer: A. Enterprise asset inventory