Governance, Standards, Compliance, and Ethics

Introduction and Context

Cloud security is not achieved by technology alone. Firewalls, encryption, identity management, monitoring, and backup systems are important, but they operate within decisions about authority, accountability, acceptable risk, legal obligations, and professional conduct. Governance provides the direction and oversight through which those decisions are made.

Cloud governance is the system by which an organisation directs, controls, and evaluates the use of cloud services. It connects business objectives with security requirements and ensures that responsibility is not lost when infrastructure, platforms, or applications are operated by a cloud service provider (CSP). Standards and frameworks provide structured ways to define and assess controls. Compliance translates external obligations into organisational requirements. Ethics guides decisions where legal compliance alone is insufficient.

A central principle is that outsourcing infrastructure does not outsource accountability. A customer may delegate operational tasks to a CSP, but it normally remains responsible for selecting an appropriate provider, configuring services correctly, protecting data, managing identities, and demonstrating compliance.

Learning Objectives

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

1. Explain the relationship between governance, risk management, compliance, and security operations.
2. Describe accountability structures and the cloud shared-responsibility model.
3. Compare ISO/IEC 27001, ISO/IEC 27017, NIST CSF, NIST RMF, CIS Controls, CSA CCM, and SOC reporting.
4. Develop a practical security baseline and connect it to audit evidence.
5. Explain data-protection obligations, professional ethics, and responsible use of technology.
6. Apply governance concepts to a cloud adoption or assurance scenario.

1. Governance, Risk, and Compliance

Governance answers the question: Who decides, according to which principles, and how is performance supervised? Security management answers how controls are implemented. Compliance asks whether applicable requirements have been met and whether evidence can demonstrate this.

These concepts are related but not identical:

A mature governance system aligns security decisions with organisational objectives. For example, a public-service application may require strong availability and accessibility, while a research system may prioritise intellectual-property protection. The correct controls depend on information sensitivity, threat exposure, legal requirements, business impact, and risk tolerance.

Governance layers

Governance can be viewed at several levels:

• Strategic governance: establishes objectives, risk appetite, investment priorities, and accountability.
• Tactical governance: translates strategy into policies, standards, architectures, contracts, and programmes.
• Operational governance: verifies that controls operate in daily practice through configuration, monitoring, incident response, and review.

A policy states intent. A standard states a mandatory technical or procedural requirement. A procedure explains how work is performed. A guideline provides recommended, but not necessarily mandatory, advice. Confusing these forms creates weak accountability.

2. Accountability in the Cloud

The shared-responsibility model

Cloud providers secure the underlying service according to the service model and contract. Customers remain responsible for some or all configuration and data-security activities. Responsibility varies:

The exact division depends on the service and contract. A customer cannot assume that a provider has configured identity permissions, encryption keys, retention schedules, or network exposure correctly. Cloud contracts and provider documentation should therefore identify responsibilities explicitly.

Accountability structures

A practical accountability structure may include:

• Board or governing body: approves risk appetite and receives significant-risk reporting.
• Executive sponsor: ensures resources and resolves organisational conflicts.
• Chief Information Security Officer or security lead: develops security strategy and oversees the security programme.
• Data owner: determines classification, permitted use, retention, and access requirements.
• System owner: ensures that a system is designed, operated, and maintained appropriately.
• Cloud architect: converts requirements into secure architectures and landing zones.
• Control owner: operates and maintains a particular control.
• Risk owner: accepts, transfers, mitigates, or avoids a risk.
• Internal audit: independently evaluates governance and controls.
• Users and administrators: follow approved procedures and report events.

A RACI matrix is useful for clarifying who is Responsible, Accountable, Consulted, and Informed. Responsibility should never be assigned vaguely to “IT” when a named role can be identified.

3. Risk-Based Governance

Security controls should be proportionate to risk rather than selected solely because they are fashionable or technically impressive. A basic risk process consists of:

1. Identify assets, business processes, data, threats, vulnerabilities, and dependencies.
2. Analyse likelihood and impact using a documented method.
3. Evaluate the result against risk appetite and criteria.
4. Select a treatment: mitigate, transfer, avoid, or accept.
5. Assign an owner and due date.
6. Monitor residual risk and reassess when conditions change.

A qualitative risk matrix may classify likelihood and impact as low, medium, or high. Quantitative analysis can sometimes estimate annual loss, but estimates should not create false precision. One commonly used model is:

where ALE is annualised loss expectancy in currency per year, SLE is single-loss expectancy in currency, and ARO is annualised rate of occurrence expressed as expected events per year. The model assumes that loss magnitude and event frequency can be estimated sufficiently for decision-making. It is less reliable when events are highly dependent, rare, rapidly changing, or difficult to value. It should support, not replace, professional judgement.

For example, if a disruption is estimated to cause a loss of £40,000 per incident and is expected 0.25 times per year, then:

This result does not mean that exactly £10,000 will be lost. It is an expected planning value. A control costing £6,000 annually may be reasonable, but the decision must also consider legal duties, safety, reputation, concentration risk, and the possibility of catastrophic outcomes.

4. Security Policies and Baselines

A security baseline is a defined minimum set of security requirements for a system, environment, account, or service. Baselines reduce inconsistent configuration and provide an objective audit reference.

A cloud baseline may include:

• multifactor authentication for privileged and remote access;
• least privilege and role-based access;
• central identity federation and timely removal of leavers;
• encryption in transit and at rest where appropriate;
• controlled key ownership, rotation, recovery, and separation of duties;
• logging of administrative, authentication, and data-access events;
• protected, time-synchronised log storage;
• vulnerability and patch management;
• hardened images and infrastructure-as-code review;
• network segmentation and restricted management paths;
• tested backup and recovery procedures;
• approved regions, data locations, and retention periods;
• incident reporting and escalation requirements;
• supplier and subcontractor assurance.

Baselines should be measurable. “Use secure configurations” is weak. “All internet-facing virtual machines must use an approved hardened image, receive critical patches within the defined service level, and send authentication logs to the central monitoring service” is more testable.

A baseline is not a complete security programme. It must be supplemented by threat modelling, application security, resilience planning, privacy controls, workforce training, and continuous improvement.

5. Major Standards and Frameworks

Frameworks differ in purpose. Some define management-system requirements, some provide guidance, some organise technical safeguards, and some provide assurance reporting. They are complementary rather than interchangeable.

ISO/IEC 27001

ISO/IEC 27001:2022 specifies requirements for an information security management system (ISMS). An ISMS is a management system based on organisational context, leadership, planning, support, operation, performance evaluation, and improvement. The organisation determines its information-security risks, selects controls, documents applicability, measures performance, and improves the system.

The standard is risk-based and can support certification by an independent certification body. Certification does not mean that every possible threat is eliminated or that every customer configuration is secure. It means that the certified scope has been assessed against the standard’s requirements at a point in time and through continuing surveillance arrangements.

The 2022 edition uses a set of controls in Annex A grouped into four themes: organisational, people, physical, and technological controls. An organisation must justify control selection in its Statement of Applicability; it should not blindly implement every control without considering context.

ISO/IEC 27017

ISO/IEC 27017 provides cloud-specific information-security guidance based on ISO/IEC 27002. It addresses controls relevant to cloud service providers and cloud customers, including division of responsibilities, removal of customer assets, virtual-machine protection, administrative operations, and monitoring. It is guidance rather than a standalone replacement for ISO/IEC 27001 certification. A provider may use it to enhance its cloud control environment, while a customer can use it to define procurement and operational expectations.

NIST Cybersecurity Framework 2.0

The NIST CSF 2.0 is a flexible framework for managing cybersecurity risk. Its six Functions are:

• Govern: establish and monitor cybersecurity risk strategy, roles, policy, and oversight.
• Identify: understand assets, suppliers, risks, and organisational context.
• Protect: implement safeguards for access, awareness, data, platforms, and technology.
• Detect: find and analyse anomalies and possible incidents.
• Respond: manage incidents, communicate, and contain impact.
• Recover: restore assets and operations and improve resilience.

The CSF is not a certification standard. Organisations can create a Current Profile showing present practices and a Target Profile describing desired outcomes, then prioritise gaps.

NIST Risk Management Framework

NIST RMF, described in NIST SP 800-37 Rev. 2, provides a structured lifecycle for managing security and privacy risk in information systems. Its classic steps are:

1. Prepare
2. Categorize
3. Select
4. Implement
5. Assess
6. Authorize
7. Monitor

The authorizing official makes an explicit risk decision based on security and privacy evidence. RMF is especially relevant in government and regulated environments, but its lifecycle is useful more broadly. Categorization considers potential impact on confidentiality, integrity, and availability. Controls are selected and tailored according to the system’s category and context.

CIS Controls

The CIS Controls are prioritized safeguards designed to reduce common cyber risks. CIS Controls v8 and subsequent updates organise safeguards across areas such as asset inventory, software inventory, data protection, secure configuration, account management, vulnerability management, audit logging, malware defenses, and incident response. Implementation Groups help organisations select a practical starting point according to risk and resources.

The Controls are operationally useful, but they do not by themselves constitute a complete governance or legal-compliance system. They should be mapped to policies, risk decisions, cloud services, and evidence.

Cloud Security Alliance Cloud Controls Matrix

The CSA Cloud Controls Matrix (CCM) is a cloud-focused control framework. It maps cloud-security domains such as identity and access management, data security, application and interface security, logging and monitoring, interoperability, and supply-chain management. CCM can assist with cloud procurement questionnaires, control mapping, provider assessment, and shared-responsibility analysis.

SOC reporting

Service Organization Control reports are assurance reports issued under professional attestation standards. Common forms include:

• SOC 1: controls relevant to user entities’ internal control over financial reporting.
• SOC 2: controls relevant to one or more Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy.
• SOC 3: a general-use report providing a less detailed presentation of SOC 2 subject matter.

A Type I report evaluates the design of controls at a specified date. A Type II report evaluates design and operating effectiveness over a stated period and normally includes testing results. Customers should examine scope, system description, complementary user-entity controls, exceptions, subservice organisations, testing period, and auditor conclusions. Possessing a SOC 2 report does not prove that the customer has configured its cloud environment securely.

Framework comparison

6. Audit, Evidence, and Continuous Assurance

An audit compares evidence against defined criteria. Evidence may include policies, architecture diagrams, access reviews, tickets, configuration exports, vulnerability reports, training records, incident exercises, provider attestations, and interview results.

Good evidence is:

• relevant to the control and audit period;
• complete enough to support a conclusion;
• reliable and protected from alteration;
• attributable to a system or responsible person;
• reproducible by an independent reviewer;
• retained according to legal and organisational requirements.

A control has two dimensions:

1. Design effectiveness: whether the control, if implemented as described, can address the risk.
2. Operating effectiveness: whether it actually operated consistently during the relevant period.

For example, a policy requiring quarterly privileged-access reviews demonstrates design intent. Evidence of completed reviews, identified exceptions, approvals, and remediation demonstrates operation. A screenshot taken once is rarely sufficient evidence of continuous compliance.

Audit findings should identify the condition, criterion, cause, effect or risk, and agreed corrective action. Management should track remediation to closure and validate that the underlying cause—not only the visible symptom—has been addressed.

7. Data Protection and Compliance Obligations

Cloud compliance begins with identifying applicable jurisdictions, sectors, data subjects, contractual commitments, and processing activities. Common obligations may concern privacy, financial records, health information, employment records, critical infrastructure, electronic communications, or public-sector information.

Core data-protection principles commonly include:

• lawfulness, fairness, and transparency;
• purpose limitation;
• data minimisation;
• accuracy;
• storage limitation;
• confidentiality and integrity;
• accountability.

Exact legal duties vary by jurisdiction. Organisations should obtain qualified legal advice rather than treating a general framework as legal interpretation.

A practical compliance analysis asks:

1. What data is collected, and why?
2. Who is the controller, owner, processor, or equivalent party?
3. Where is data stored, processed, and transferred?
4. What retention and deletion rules apply?
5. What rights do individuals have?
6. What security measures are appropriate to the risk?
7. What breach-notification and cooperation duties exist?
8. Which subcontractors and subprocessors are involved?

Contracts should address confidentiality, security controls, audit or assurance rights, incident notification, data location, deletion or return, subcontracting, service continuity, and exit assistance. Data residency is not automatically the same as data sovereignty: location may affect legal control, access by authorities, and contractual enforceability.

8. Professional Ethics in Cloud Security

Ethical practice is necessary because security professionals possess privileged access and may make decisions affecting privacy, safety, livelihoods, and public trust. Professional ethics includes:

• protecting confidentiality and using access only for authorised purposes;
• being honest about control effectiveness, uncertainty, and residual risk;
• avoiding conflicts of interest and disclosing them when they arise;
• respecting privacy and collecting only necessary information;
• reporting vulnerabilities responsibly;
• preserving evidence and avoiding misleading audit claims;
• challenging unsafe instructions through appropriate escalation;
• maintaining competence and recognising limits;
• considering accessibility, discrimination, and unequal impacts.

Legal compliance is a floor, not a complete ethical standard. For example, a system may legally collect extensive behavioural data while still violating reasonable expectations of privacy. Similarly, a provider may technically meet contract wording while obscuring material limitations from customers.

Artificial intelligence introduces additional governance concerns. Organisations should define approved uses, protect confidential prompts and training data, validate outputs, record human accountability, test for bias, and prevent automated decisions from escaping appropriate oversight. AI-generated compliance evidence must be independently verified; fluent text is not proof that a control operated.

9. Applied Case: Northbridge Health Services Cloud Migration

This is an illustrative case.

Background

Northbridge Health Services, a regional healthcare organisation, plans to move appointment systems and clinical-support applications to a public cloud. The environment will contain personal and health-related information. The organisation has a small security team, uses several suppliers, and must demonstrate compliance to regulators and hospital partners.

Problem

An initial assessment finds shared administrator accounts, inconsistent logging, unclear responsibility for backups, excessive database permissions, and a contract that does not clearly define incident-notification times. The cloud provider has ISO/IEC 27001 certification and a SOC 2 Type II report, but the organisation assumes these documents prove that its own deployment is compliant.

Analysis

The assumption is incorrect. Provider assurance covers a defined service scope and control environment; it does not automatically cover Northbridge’s identities, application code, data classification, regional settings, retention, or customer-managed keys. The organisation must also establish its own governance and evidence.

Northbridge categorizes the systems according to confidentiality, integrity, and availability impact. It identifies clinical safety and privacy as high-impact concerns. The board appoints an executive risk owner, while data owners define permitted use and retention. A RACI matrix assigns responsibilities between Northbridge, the provider, application suppliers, and internal teams.

Approach and solution

Northbridge adopts the NIST CSF as its communication structure and uses ISO/IEC 27001 principles to formalise its ISMS. CSA CCM and ISO/IEC 27017 guidance support the cloud-control assessment, while CIS Controls guide technical priorities.

The organisation then:

1. removes shared accounts and requires federated multifactor authentication;
2. creates separate administrative roles and performs quarterly access reviews;
3. classifies data and restricts approved regions and processing locations;
4. encrypts sensitive data and documents key-management responsibilities;
5. sends administrative, authentication, and clinical-access events to protected central logging;
6. defines backup ownership, recovery objectives, and restoration tests;
7. uses hardened infrastructure-as-code templates with peer review;
8. updates supplier contracts for breach notification, subprocessors, deletion, and exit support;
9. creates a control-to-evidence register;
10. performs an independent readiness review and tracks corrective actions.

Outcome

Northbridge can demonstrate not only that its provider has external assurance, but also that its own deployment has defined owners, tested controls, and retained evidence. The organisation accepts a small number of documented residual risks, with compensating controls and review dates. It avoids claiming “complete compliance” and instead reports the scope, criteria, evidence, exceptions, and improvement plan.

Learning points

• Provider certification is not customer compliance.
• Governance must assign ownership before technology is deployed.
• A framework is valuable when it changes decisions and evidence collection.
• High-impact data requires stronger justification, access control, resilience, and oversight.
• Honest statements about scope and residual risk are an ethical requirement.

10. Implementation Guidance and Common Limitations

A diploma-level practitioner can contribute effectively by using a repeatable governance cycle:

1. establish scope and business objectives;
2. inventory cloud assets, data, accounts, suppliers, and dependencies;
3. identify legal, contractual, and policy requirements;
4. select a primary framework and map supporting frameworks to it;
5. define minimum baselines and control owners;
6. automate preventative and detective checks where practical;
7. collect durable evidence;
8. test controls and investigate exceptions;
9. report risk in business language;
10. review and improve after incidents, changes, and audits.

Common limitations include framework overload, checkbox compliance, outdated inventories, poorly defined evidence, overreliance on provider marketing, unclear shared responsibility, and excessive confidence in automated compliance tools. Automation can detect a public storage bucket or missing multifactor authentication, but it may not determine whether a processing purpose is lawful or whether a risk acceptance is ethically defensible.

Contemporary cloud governance increasingly involves infrastructure-as-code policy checks, continuous control monitoring, software supply-chain assurance, confidential computing, zero-trust architectures, sovereign-cloud requirements, and AI governance. These developments do not eliminate fundamental duties: identify risk, assign accountability, implement proportionate controls, test them, and communicate truthfully.

Chapter Summary

Governance provides the authority, direction, and accountability needed to manage cloud security strategically. Risk management links security investment to business impact, while compliance and assurance provide evidence that requirements and control criteria have been addressed. The shared-responsibility model requires customers to understand exactly which activities remain theirs.

ISO/IEC 27001 supports a certifiable information-security management system; ISO/IEC 27017 adds cloud-specific guidance; NIST CSF 2.0 organises cybersecurity outcomes; NIST RMF provides a lifecycle for system authorization; CIS Controls prioritise practical safeguards; CSA CCM supports cloud-control mapping; and SOC reports provide independent assurance about defined service controls. None should be treated as automatic proof that a customer’s cloud deployment is secure or legally compliant.

Effective governance uses named owners, measurable baselines, reliable audit evidence, supplier oversight, data-protection analysis, and continuous improvement. Ethical professionals go beyond minimum compliance by protecting privacy, reporting limitations honestly, avoiding misuse of privileged access, and maintaining human accountability for consequential decisions.

Key Terms

Governance: Direction, oversight, and accountability for achieving organisational objectives.

Cloud governance: Governance applied to cloud services, configurations, providers, data, and responsibilities.

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

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

Risk owner: Person accountable for deciding how a particular risk is treated.

Security baseline: Minimum defined security requirements for a system or service.

Policy: Authoritative statement of organisational intent and mandatory direction.

Standard: Specific mandatory requirement used to implement policy consistently.

Control owner: Person responsible for operating or maintaining a control.

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

ISO/IEC 27001: Standard specifying requirements for an ISMS.

ISO/IEC 27017: Cloud-specific information-security guidance.

NIST CSF: Framework for communicating and managing cybersecurity risk.

NIST RMF: Lifecycle for preparing, categorizing, selecting, implementing, assessing, authorizing, and monitoring systems.

CIS Controls: Prioritized safeguards for reducing common cyber risks.

CSA CCM: Cloud Security Alliance control framework for cloud assurance and assessment.

SOC report: Independent report on defined service-organization controls.

Complementary user-entity controls: Customer controls assumed by a service provider’s control description.

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

Data minimisation: Limiting personal-data collection to what is necessary for a defined purpose.

Review Questions

5 Short Answer Questions

1. Why does outsourcing infrastructure to a cloud provider not eliminate customer accountability?
2. Distinguish a policy, a standard, and a procedure.
3. What is the purpose of a security baseline?
4. State the six Functions of NIST CSF 2.0.
5. Explain the difference between a SOC Type I and a SOC Type II report.

5 Long Answer Questions

1. Compare ISO/IEC 27001, NIST CSF 2.0, and CIS Controls in terms of purpose, structure, and typical use.
2. Explain how a RACI matrix and named risk owners improve cloud accountability.
3. Describe a complete cloud audit-evidence process, including design effectiveness and operating effectiveness.
4. Discuss the main data-protection questions an organisation should answer before moving sensitive data to the cloud.
5. Explain why professional ethics requires more than simple legal compliance in cloud security.

3 Analytical / Application Questions

1. A SaaS provider presents a SOC 2 Type II report, but your organisation has no access reviews, unclear retention rules, and unrestricted administrator accounts. Analyse what the report does and does not demonstrate, and propose priorities for remediation.
2. Design a minimum security baseline for a public-facing cloud application containing confidential customer data. Identify at least eight requirements and explain the risk addressed by each.
3. A business wants to accept a residual risk because a control costs more than the estimated annual loss. Analyse why ALE alone may be insufficient and recommend a governance decision process.

Multiple Choice Questions with Answers

Question 1

Which statement best describes cloud shared responsibility?

A. The cloud provider is always responsible for every security activity.

B. The customer is always responsible for physical data-centre security.

C. Security duties are divided according to the service, configuration, and contract.

D. Responsibility ends when a third-party auditor issues a report.

Correct Answer: C. Security duties are divided according to the service, configuration, and contract.

Question 2

Which ISO standard specifies requirements for an Information Security Management System?

A. ISO/IEC 27001

B. ISO/IEC 27017 בלבד

C. ISO 9001

D. ISO 22301 בלבד

Correct Answer: A. ISO/IEC 27001

Question 3

What is the primary purpose of NIST CSF 2.0?

A. To provide a mandatory cloud certification scheme

B. To organise cybersecurity-risk outcomes and communication

C. To replace all privacy legislation

D. To define accounting controls for financial reporting

Correct Answer: B. To organise cybersecurity-risk outcomes and communication

Question 4

Which NIST RMF step involves an explicit risk decision by an authorizing official?

A. Categorize

B. Implement

C. Authorize

D. Prepare

Correct Answer: C. Authorize

Question 5

A control requirement states that privileged access must use multifactor authentication. Which item is strongest evidence that the control operated during the audit period?

A. A general security slogan

B. A product brochure

C. A dated access report showing privileged accounts and MFA status

D. An unsigned draft policy

Correct Answer: C. A dated access report showing privileged accounts and MFA status

Question 6

What does a SOC 2 Type II report generally provide beyond a Type I report?

A. Testing of operating effectiveness over a stated period

B. A guarantee that every customer configuration is secure

C. A legal opinion covering every jurisdiction

D. A complete penetration test of every customer system

Correct Answer: A. Testing of operating effectiveness over a stated period

Question 7

If single-loss expectancy is £40,000 and annualised rate of occurrence is 0.25, what is the annualised loss expectancy?

A. £1,000

B. £10,000

C. £40,000

D. £160,000

Correct Answer: B. £10,000

Question 8

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

A. CSA CCM

B. NIST RMF בלבד

C. SOC 1

D. ISO 9001

Correct Answer: A. CSA CCM

Question 9

Which action best reflects data minimisation?

A. Retaining all collected data indefinitely

B. Collecting only data necessary for a defined purpose

C. Copying production data into every development environment

D. Allowing all employees to access personal data

Correct Answer: B. Collecting only data necessary for a defined purpose

Question 10

Which ethical practice is most appropriate when a security professional discovers that an audit statement materially overstates control effectiveness?

A. Ignore it because the statement was prepared by management

B. Delete the supporting evidence

C. Report the concern through an appropriate escalation route

D. Publish confidential customer data to prove the issue

Correct Answer: C. Report the concern through an appropriate escalation route