Security Governance, Ethics and Compliance

Introduction

Cloud security is not governed by technology alone. Firewalls, encryption, identity controls and monitoring are effective only when an organisation has clearly defined responsibilities, approved policies, accountable owners and processes for demonstrating compliance. In cloud environments, these matters become more complex because infrastructure, applications, data and operational duties are distributed across the customer, cloud service provider, software vendors, regulators and business partners.

Security governance is the system through which an organisation directs, controls and reviews security activities. It connects business objectives with risk decisions and security controls. Ethics provides the principles that guide decisions when legal rules or contracts do not provide a complete answer. Compliance establishes the obligations that an organisation must meet, including laws, regulations, standards and contractual requirements.

A sound governance programme therefore answers five practical questions:

1. What information and services must be protected?
2. What risks could affect them?
3. Who has authority and accountability for managing those risks?
4. Which controls are required, and how will their effectiveness be demonstrated?
5. How should the organisation respond when obligations, risks or ethical values conflict?

This chapter introduces foundational governance and compliance concepts relevant to cloud computing. It focuses on NIST, ISO/IEC 27001, the Cloud Security Alliance Cloud Controls Matrix (CSA CCM), privacy obligations, contracts, audits, data residency and digital ethics.

Learning Objectives

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

• distinguish governance, risk management, compliance and security operations;
• explain policy hierarchy, control ownership and accountability;
• apply the shared-responsibility model to cloud services;
• interpret the purposes of NIST, ISO/IEC 27001 and CSA CCM;
• identify important privacy, contractual, audit and data-residency obligations;
• analyse ethical issues involving cloud data and automated systems; and
• recommend practical governance improvements for a cloud deployment.

1. Governance, Risk and Compliance

1.1 Security governance

Security governance is the leadership framework used to establish direction, authority, oversight and accountability for protecting information and technology. It is concerned with decisions such as risk appetite, investment priorities, acceptable use, regulatory obligations and escalation of significant incidents.

Governance is different from management and operations. A board or executive committee may approve the organisation’s risk appetite and security policy. Managers translate that direction into programmes, budgets and procedures. Operational teams implement controls, monitor systems and respond to events. These activities are related but should not be confused.

Good governance is risk-based rather than purely technology-based. It recognises that a low-value test system and a national payment platform should not receive identical controls. The required level of protection depends on information sensitivity, business impact, threat exposure, legal obligations and the organisation’s risk tolerance.

1.2 Risk governance

Risk is the possibility that uncertainty will affect objectives. In security, risk commonly arises when a threat can exploit a vulnerability and produce an unwanted impact. A simple qualitative model is:

Likelihood expresses how probable an event is, while impact expresses the severity of its consequences. This relationship is a decision aid, not a universal measurement law. Organisations may use numerical scales, financial estimates or qualitative categories. The scales must be defined consistently, and the resulting rating should not be treated as a precise prediction.

Risk governance includes:

• identifying assets, processes and dependencies;
• assessing threats, vulnerabilities and potential impacts;
• selecting treatments such as reduction, transfer, avoidance or acceptance;
• assigning risk owners;
• recording decisions in a risk register; and
• reviewing risks when systems, threats, suppliers or laws change.

Risk acceptance must be explicit. A technical team should not silently accept a risk simply because remediation is inconvenient. Acceptance should be made by an authorised person whose level of authority is appropriate to the potential impact.

1.3 Compliance

Compliance is adherence to applicable obligations. These may arise from:

• legislation and regulation;
• industry requirements;
• contractual commitments;
• internal policies;
• recognised standards; and
• customer or insurer requirements.

Compliance is not identical to security. An organisation can satisfy a checklist while remaining vulnerable, and it can have strong security practices while lacking evidence required by a regulator or contract. Effective programmes integrate compliance with risk management and security engineering.

2. Policy, Standards and Control Ownership

2.1 Policy hierarchy

A policy states management intent and mandatory organisational direction. It should be approved by an appropriate authority, reviewed periodically and communicated to relevant personnel. Policies are usually supported by a hierarchy of more specific documents:

1. Policy: what the organisation requires and why.
2. Standard: mandatory technical or procedural criteria.
3. Procedure: the approved sequence for performing an activity.
4. Guideline: recommended practice that allows professional judgement.
5. Record or evidence: proof that an activity occurred or a control operated.

For example, an access-control policy may require least privilege. A standard may require multi-factor authentication for privileged accounts. A procedure may explain how an administrator requests, approves and reviews access. A system record may demonstrate that the review occurred.

Policies should define scope, roles, exceptions, enforcement, review frequency and links to applicable obligations. Poor policies are excessively vague, impossible to follow or disconnected from actual technology. A policy that requires controls unavailable in the organisation’s cloud architecture creates false assurance.

2.2 Control ownership and accountability

A control is a safeguard that prevents, detects, corrects or compensates for an unwanted event. Examples include encryption, access review, vulnerability management, backup testing and incident reporting.

Control ownership means responsibility for ensuring that a control is designed, implemented, maintained and evidenced. Accountability is the obligation to answer for results. A person may delegate a task but generally cannot delegate accountability without formal transfer of authority.

A useful responsibility assignment distinguishes:

• Accountable: ultimately answerable for the outcome;
• Responsible: performs or coordinates the work;
• Consulted: provides expertise or approval input; and
• Informed: receives relevant information.

This is commonly represented in a RACI matrix. For a cloud backup control, the infrastructure manager may be accountable, a cloud operations engineer responsible, the data owner consulted and internal audit informed. The exact assignment depends on the organisation.

Control ownership must be mapped across the shared-responsibility model. A cloud provider may be responsible for physical data-centre security and hypervisor protection, while the customer remains responsible for identity configuration, data classification and permissions. The provider’s security does not automatically secure a customer’s poorly configured storage bucket.

2.3 Control lifecycle

Controls should be managed throughout their lifecycle:

1. identify the risk and control objective;
2. design a proportionate control;
3. assign ownership and resources;
4. implement the control;
5. collect evidence of operation;
6. test design and operating effectiveness;
7. remediate deficiencies; and
8. retire or revise the control when circumstances change.

Control effectiveness has two dimensions. Design effectiveness asks whether the control, if operated as intended, could address the risk. Operating effectiveness asks whether it actually operated consistently over a defined period. A well-designed access review that was never performed is not operating effectively.

3. Cloud Governance and the Shared-Responsibility Model

Cloud services are commonly delivered as infrastructure as a service (IaaS), platform as a service (PaaS) or software as a service (SaaS). As the provider manages more of the technology stack, the customer manages fewer underlying components, but the customer’s obligations do not disappear.

These are general patterns, not universal rules. The service agreement and provider documentation determine the actual allocation. Customers should document assumptions rather than relying on the service model label.

Cloud governance should include:

• an approved cloud account and subscription structure;
• identity federation and strong authentication;
• secure configuration baselines;
• asset and data inventories;
• logging and monitoring responsibilities;
• incident-notification procedures;
• backup and recovery requirements;
• supplier and subcontractor oversight; and
• exit, portability and deletion arrangements.

A cloud contract should be read together with technical documentation, service-level commitments, security addenda and privacy terms. Marketing statements are not a substitute for enforceable obligations or technical evidence.

4. Foundational Security Frameworks

4.1 NIST Cybersecurity Framework

The NIST Cybersecurity Framework (CSF) provides a flexible way to manage cybersecurity risk. Its core functions are:

• Govern: establish and monitor cybersecurity strategy, expectations and policy;
• Identify: understand assets, risks, suppliers and business context;
• Protect: implement safeguards such as identity management, training and data security;
• Detect: discover and analyse anomalous events;
• Respond: contain, communicate and manage incidents; and
• Recover: restore capabilities and improve after disruption.

The framework is outcome-oriented. It does not prescribe one technology or a single organisational structure. A small organisation can use it to create a basic risk profile, while a larger organisation can use it to compare a current profile with a target profile.

NIST publications also provide detailed guidance for areas such as security controls, privacy risk, incident response and digital identity. Organisations should identify the specific publication and version being used because guidance evolves.

4.2 ISO/IEC 27001

ISO/IEC 27001 specifies requirements for an information security management system (ISMS). An ISMS is a systematic management process for establishing, implementing, maintaining and continually improving information security.

Important ISMS features include:

• organisational context and interested parties;
• leadership commitment and policy;
• risk assessment and risk treatment;
• defined objectives and resources;
• documented information;
• competence and awareness;
• performance evaluation and internal audit; and
• corrective action and continual improvement.

The standard uses a management-system perspective. Certification, where obtained through an accredited certification process, provides evidence that the organisation’s ISMS was assessed against the standard’s requirements within a defined scope. It does not mean that every system is risk-free or that every control is identical across organisations.

The Statement of Applicability records which controls are applicable, their implementation status and justification for inclusion or exclusion. Scope is critical: an ISO/IEC 27001 certificate covering one business unit does not automatically cover all cloud accounts or services.

4.3 CSA Cloud Controls Matrix

The CSA CCM is a cloud-focused control framework that maps security practices to cloud-relevant domains, such as identity and access management, data security, governance, logging and monitoring, infrastructure security and application security. It helps customers and providers discuss expectations using a common vocabulary.

The CCM can support:

• cloud supplier due diligence;
• control mapping between frameworks;
• procurement requirements;
• internal assessment; and
• preparation for assurance reviews.

It is a control framework, not a replacement for law, a contract, a risk assessment or provider-specific architecture documentation. Framework mappings should be validated rather than assumed to be exact equivalences.

4.4 Comparing the frameworks

Frameworks can be used together. For example, an organisation may use NIST CSF to define its target outcomes, ISO/IEC 27001 to operate its management system and CSA CCM to assess cloud-specific controls.

5. Privacy, Data Protection and Data Residency

5.1 Privacy principles

Privacy laws differ by jurisdiction, but many contain related principles. These commonly include lawfulness and transparency, purpose limitation, data minimisation, accuracy, retention limitation, confidentiality and accountability. Organisations should identify the law applicable to the individuals, organisation, processing activity and location involved.

Privacy governance begins with data mapping. The organisation should know:

• what personal data it collects;
• whose data it is;
• why it is processed;
• the legal basis or authority for processing;
• where it is stored and transferred;
• who can access it;
• how long it is retained; and
• how it will be deleted or returned.

Personal data is broader than obvious identifiers. Depending on applicable law, it may include account identifiers, location information, online identifiers, usage records and inferred profiles. Sensitive or special-category data may require stronger safeguards and additional legal conditions.

Privacy by design means considering privacy during architecture, procurement and development rather than adding it after deployment. Practical measures include collecting fewer attributes, separating identifiers from content, using role-based access, encrypting data, limiting retention and testing deletion processes.

5.2 Roles and processing relationships

A cloud customer may determine the purposes and means of processing, while a provider processes data on the customer’s instructions. Legal terminology varies, but contracts should clearly establish roles, permitted processing, confidentiality, security measures, subprocessors, assistance with individual rights, breach notification, audits and deletion or return at termination.

A privacy impact assessment or data protection impact assessment may be appropriate where processing is likely to create significant risks, such as large-scale monitoring, sensitive data processing or systematic profiling. The assessment should identify risks to individuals, not merely risks to the organisation.

5.3 Data residency and sovereignty

Data residency refers to the physical or legal location where data is stored or processed. Data sovereignty concerns the authority of the jurisdiction whose laws may apply to data or service operations. A service may replicate data across regions, route support access through another country or use international subprocessors.

Residency requirements should therefore address more than the primary storage region. Organisations should ask about:

• backups and disaster-recovery copies;
• metadata and logs;
• technical support access;
• remote administration;
• subprocessors;
• lawful government access;
• cross-border transfer mechanisms; and
• secure deletion and media disposal.

A region selector alone does not prove legal compliance. Requirements must be translated into contractual terms, provider configuration and evidence.

6. Contracts, Audits and Assurance

6.1 Security clauses in cloud contracts

A cloud contract should allocate responsibilities clearly and provide practical assurance rights. Important subjects include:

• security control commitments;
• privacy roles and processing instructions;
• confidentiality and personnel vetting;
• incident notification and cooperation;
• vulnerability management and patching expectations;
• availability, recovery objectives and backup arrangements;
• audit reports and independent certifications;
• subcontractor disclosure and change notification;
• data location and transfer controls;
• retention, return and deletion;
• service termination and exit support; and
• liability, indemnity and insurance.

A service-level agreement usually focuses on availability and performance. It should not be mistaken for a complete security agreement. Security and privacy obligations need sufficient specificity to be tested.

6.2 Audits and assurance reports

An audit is a systematic, independent evaluation against defined criteria. Assurance may include certifications, attestation reports, penetration-test summaries, customer audits, vulnerability reports and management representations. Each type has limitations.

When reviewing a provider report, consider:

1. What standard or control criteria were used?
2. What period and services were covered?
3. Was the report an opinion on design, operation or both?
4. Were exceptions identified?
5. Which customer responsibilities remain?
6. Were subcontractors included?
7. Does the report cover the purchased region and service?
8. Is the evidence current enough for the decision?

An assurance report is evidence, not proof that every customer configuration is secure. Complementary customer controls may be listed in the report. These controls must be implemented by the customer for the assurance conclusion to be meaningful.

6.3 Evidence and audit readiness

Evidence should be reliable, relevant, complete and protected from unauthorised alteration. Examples include access-review records, policy approvals, configuration exports, training records, incident exercises, backup restoration results and supplier assessments.

Evidence collection should be designed into operations. Retrospectively creating records can produce gaps and undermine credibility. Automated evidence can improve consistency, but automation itself must be governed and periodically validated.

7. Digital Ethics and Responsible Cloud Use

Law sets minimum requirements; ethics asks what should be done responsibly. Ethical cloud practice protects human dignity, autonomy, fairness, safety and trust.

Key ethical issues include:

• Transparency: people should receive understandable information about significant data use and automated decisions.
• Purpose integrity: data collected for one purpose should not be casually reused for an unrelated purpose.
• Fairness: systems should be evaluated for discriminatory outcomes and unequal access.
• Accountability: an organisation must retain human responsibility for decisions delegated to software or cloud providers.
• Proportionality: surveillance and data collection should be proportionate to a legitimate objective.
• Security and safety: convenience should not justify avoidable exposure of people or essential services.
• Human oversight: high-impact decisions require meaningful review and avenues for challenge.

Artificial intelligence increases these concerns. Cloud AI services may process prompts, training data, logs and generated outputs in ways users do not fully understand. Before using such a service, an organisation should determine whether data is retained, used for model improvement, transferred internationally or accessible to provider personnel. It should also assess accuracy, bias, explainability, intellectual-property concerns and the risk of disclosing confidential information through prompts.

Ethical governance is not achieved by a single committee statement. It requires impact assessment, clear ownership, testing with representative data, monitoring, incident reporting and mechanisms for affected people to raise concerns.

8. Applied Case: Selecting a Cloud Platform for a Health-Services Portal

The following is an illustrative case.

Background

A regional health organisation plans to place an appointment and patient-communication portal in the cloud. The portal will process identity information, appointment details and limited clinical information. The organisation operates in two jurisdictions and must comply with privacy laws, contractual obligations and health-sector expectations.

Problem

A project team proposes a low-cost SaaS platform. The supplier advertises encryption and compliance certifications but cannot initially confirm the location of backups, the use of subprocessors or the deletion process at contract termination. The project manager argues that the supplier’s certification removes the need for a separate assessment.

Analysis

The organisation first classifies the information and identifies affected individuals, processing purposes and legal obligations. It then maps the service’s data flows, including production storage, backups, logs, support access and disaster recovery. The team applies the shared-responsibility model: the provider manages the application platform, but the customer remains responsible for user provisioning, data accuracy, configuration, lawful use and selecting an appropriate service.

The certification is reviewed for scope, assessment period, control criteria, exceptions and complementary customer controls. A privacy impact assessment identifies risks associated with international support access, excessive retention and unauthorised administrator access.

Approach and solution

The organisation requires the supplier to:

• store primary and backup data in approved jurisdictions;
• disclose subprocessors and obtain approval for material changes;
• provide contractual breach notification within a defined period;
• support access, correction and deletion obligations;
• use strong authentication and segregated administrative access;
• provide independent assurance reports and relevant test summaries;
• delete or return data securely at termination; and
• support an exit plan and export of records in a usable format.

The customer implements federated identity, role-based access, periodic access reviews, data retention rules, logging and an incident playbook. A governance committee approves residual risks and records the decision.

Outcome

The supplier meets most requirements but cannot provide the required backup location. The organisation either selects an alternative service or obtains documented legal and risk approval for a compensating arrangement. The final decision is based on evidence and risk, not on a generic compliance claim.

Learning points

1. A provider certification has a defined scope and does not replace customer governance.
2. Data location includes backups, logs and support access.
3. Contracts should make security and privacy obligations testable.
4. The customer must govern identity, configuration, data use and exit.
5. Residual risk should be explicitly accepted by an authorised owner.

9. Challenges, Limitations and Best Practices

Governance programmes face several difficulties. Regulations may conflict or change. Cloud services evolve rapidly, making documentation outdated. Framework mappings may create an illusion of completeness. Small organisations may lack specialist privacy, audit or security staff. Excessive controls can obstruct innovation, while weak controls expose people and the organisation to harm.

Practical best practices include:

• maintain an inventory of cloud services, data and owners;
• classify data before selecting a service;
• use a formal cloud supplier assessment;
• document the shared-responsibility boundary;
• require strong identity and privileged-access controls;
• map obligations to controls and evidence;
• review provider assurance reports critically;
• test backup restoration and incident communications;
• monitor configuration drift and access changes;
• establish retention, deletion and exit procedures;
• conduct privacy and ethical impact assessments for high-risk uses; and
• review policies, risks and contracts whenever the service or law changes.

Governance is a continual process. A control that was appropriate during procurement may become inadequate after a new feature, data type, threat or legal requirement is introduced.

Chapter Summary

Security governance connects organisational objectives, risk decisions, policies, controls and accountability. Governance establishes direction and oversight; management coordinates resources; operations implement safeguards; and assurance evaluates whether controls are suitable and effective.

Cloud responsibility is shared. Providers usually secure the underlying service, while customers remain responsible for appropriate configuration, identity, data use, compliance and many operational decisions. NIST CSF offers a flexible cybersecurity risk lifecycle, ISO/IEC 27001 provides an auditable information security management system, and CSA CCM supplies a cloud-focused control vocabulary. These frameworks complement, rather than replace, laws, contracts and risk assessments.

Privacy governance requires data mapping, purpose limitation, minimisation, retention control, appropriate safeguards and accountability. Data residency must consider backups, logs, support access and subprocessors, not merely the selected storage region. Contracts should define security, privacy, incident, audit, subcontractor, deletion and exit obligations. Assurance reports must be interpreted according to their scope, criteria, period and customer responsibilities.

Finally, ethical cloud practice extends beyond legal compliance. Transparency, fairness, proportionality, human oversight and accountability are especially important when cloud platforms support surveillance, profiling or artificial intelligence. Effective governance is evidence-based, risk-informed and continually improved.

Key Terms

Governance: Direction, oversight and accountability used to achieve organisational objectives.

Risk: The effect of uncertainty on objectives, often assessed through likelihood and impact.

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

Risk owner: An authorised person accountable for managing a particular risk.

Control: A safeguard that prevents, detects, corrects or compensates for an unwanted event.

Control owner: The person accountable for the design, operation and evidence of a control.

Policy: Approved management direction stating mandatory organisational requirements.

Standard: A mandatory, specific criterion supporting a policy.

Procedure: An approved sequence of steps for performing an activity.

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

ISMS: Information Security Management System used to manage information-security risks.

NIST CSF: A framework for managing cybersecurity risk through defined functions and outcomes.

CSA CCM: A cloud-specific matrix of security controls and domains.

Privacy by design: Incorporating privacy protections throughout system and service design.

Data residency: The physical or legal location in which data is stored or processed.

Data sovereignty: The authority of laws and jurisdictions over data or related operations.

Assurance: Evidence-based confidence that requirements or controls are being met.

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

Digital ethics: Principles guiding responsible technology use beyond minimum legal compliance.

Review Questions

5 Short Answer Questions

1. What is the difference between security governance and security operations?
2. Define control ownership and explain why it matters in cloud computing.
3. Name the six core functions of the NIST Cybersecurity Framework.
4. Why does a cloud region selector not by itself prove data-residency compliance?
5. What is the purpose of a Statement of Applicability in ISO/IEC 27001?

5 Long Answer Questions

1. Explain how policy, standards, procedures and evidence form a governance hierarchy. Give a cloud-security example.
2. Compare NIST CSF, ISO/IEC 27001 and CSA CCM in terms of purpose and practical use.
3. Discuss how a customer should evaluate a cloud provider’s audit or assurance report.
4. Explain the relationship between privacy by design, data minimisation and retention limitation.
5. Describe the main security and governance obligations that should appear in a cloud contract.

3 Analytical / Application Questions

1. An organisation stores customer records in a SaaS platform. The provider manages the application but allows customer administrators to create users and export data. Identify likely provider and customer responsibilities, and propose three customer controls.
2. A provider’s primary database is located in an approved country, but support engineers and disaster-recovery backups may be located elsewhere. Analyse the residency and sovereignty questions the customer should investigate.
3. A company wants to use a public AI cloud service to analyse employee performance records. Develop a governance decision that considers privacy, fairness, transparency, security, human oversight and residual risk.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily a governance responsibility?

A. Approving the organisation’s risk appetite

B. Resetting a user password

C. Installing an operating-system patch

D. Investigating an individual log entry

Correct Answer: A. Approving the organisation’s risk appetite

Question 2

What does a control owner normally ensure?

A. That every risk is eliminated

B. That a control is designed, operated and evidenced

C. That only the cloud provider is audited

D. That policies never change

Correct Answer: B. That a control is designed, operated and evidenced

Question 3

Which NIST CSF function focuses on discovering and analysing anomalous events?

A. Protect

B. Recover

C. Detect

D. Govern

Correct Answer: C. Detect

Question 4

What is the primary emphasis of ISO/IEC 27001?

A. A cloud provider’s pricing model

B. An information security management system

C. A programming language standard

D. A replacement for privacy law

Correct Answer: B. An information security management system

Question 5

Which statement best describes the CSA Cloud Controls Matrix?

A. A cloud-focused control framework and vocabulary

B. A legally binding privacy regulation in every country

C. A guarantee that customer systems are secure

D. A method for calculating network bandwidth

Correct Answer: A. A cloud-focused control framework and vocabulary

Question 6

In a typical IaaS arrangement, which responsibility usually remains with the customer?

A. Protecting the provider’s physical data centre

B. Managing the cloud provider’s hypervisor

C. Configuring operating-system access and customer identities

D. Maintaining the provider’s power supply

Correct Answer: C. Configuring operating-system access and customer identities

Question 7

Which item should be examined when assessing data residency?

A. Only the colour of the provider’s dashboard

B. Backups, logs and support access

C. The number of provider employees

D. The provider’s advertising slogan

Correct Answer: B. Backups, logs and support access

Question 8

What is the difference between design effectiveness and operating effectiveness?

A. Design concerns cost; operating concerns revenue

B. Design asks whether a control could address risk; operating asks whether it actually worked consistently

C. Design applies only to providers; operating applies only to customers

D. There is no difference

Correct Answer: B. Design asks whether a control could address risk; operating asks whether it actually worked consistently

Question 9

Which is an ethical concern in the use of cloud-based artificial intelligence?

A. Whether the system has a sufficiently colourful interface

B. Whether people can understand and challenge significant decisions

C. Whether the provider offers unlimited storage

D. Whether the service uses a short product name

Correct Answer: B. Whether people can understand and challenge significant decisions

Question 10

A risk has a likelihood rating of 4 and an impact rating of 5 on defined ordinal scales. Using Risk = Likelihood × Impact, what is the indicative score?

A. 9

B. 20

C. 45

D. 1.25

Correct Answer: B. 20