Shared Responsibility, Governance and Security Strategy

Introduction

Cloud computing changes the location, ownership and operation of information systems, but it does not eliminate security responsibility. Instead, responsibility is distributed among the cloud service provider (CSP), the cloud customer, users, software suppliers and, in some cases, regulators and managed-service partners. A secure cloud environment therefore requires more than technical controls. It requires governance: the structures, policies, decision rights, accountability mechanisms and assurance processes through which an organisation directs and controls cloud use.

This chapter develops a practical and strategic understanding of shared responsibility, cloud governance and security strategy. It explains how responsibility changes across infrastructure, platform and software services; how policies and roles convert organisational objectives into enforceable controls; how risk appetite guides decisions; and how guardrails enable innovation without permitting unacceptable exposure.

Learning Objectives

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

1. Interpret shared-responsibility models across IaaS, PaaS and SaaS.
2. Distinguish governance, risk management, compliance and security operations.
3. Define cloud security policies, roles, accountability and escalation paths.
4. Explain risk appetite, risk tolerance and risk treatment in cloud decisions.
5. Design practical cloud guardrails aligned with business and digital-transformation objectives.
6. Evaluate governance structures, assurance mechanisms and common implementation weaknesses.
7. Apply these concepts to a realistic cloud adoption scenario.

1. Cloud Security as a Governance Problem

Traditional security models often assumed that an organisation owned its data centre, networks, servers and security tooling. Cloud computing introduces a shared operating model. Physical facilities, hardware, hypervisors and some platform components may be controlled by a CSP, while the customer controls identities, configurations, data and applications. The boundary is contractual and technical rather than purely physical.

Security must therefore be considered at three levels:

• Business level: What outcomes must be protected? Examples include customer trust, service availability, intellectual property and regulatory compliance.
• Governance level: Who may make decisions, approve exceptions, accept risk and verify performance?
• Technical level: Which preventive, detective, corrective and recovery controls implement those decisions?

A technically strong control can still fail if no one owns it, if it is not funded, or if the organisation has no process for responding to exceptions. Conversely, a well-written policy is ineffective if it cannot be translated into automated and measurable controls.

Governance is not the same as bureaucracy. Effective governance creates repeatable decision-making, reduces ambiguity and allows safe innovation at scale. Poor governance either permits uncontrolled risk or creates so many delays that teams bypass official processes.

2. The Shared-Responsibility Model

The shared-responsibility model states that the CSP and customer each have defined security duties. The exact boundary depends on the service model, contract, architecture and configuration. “The provider secures the cloud” does not mean that the provider secures everything deployed in the cloud. Similarly, “the customer secures what it controls” does not mean that the customer is responsible for the provider’s data-centre guards or hypervisor design.

2.1 Responsibility in IaaS, PaaS and SaaS

In Infrastructure as a Service (IaaS), the customer rents foundational computing resources. The provider generally secures physical infrastructure, facilities and virtualisation. The customer normally secures operating systems, installed software, identities, network rules, data and workload configuration.

In Platform as a Service (PaaS), the provider manages more of the operating system and runtime environment. The customer remains responsible for application logic, access permissions, data, secrets and secure configuration. PaaS reduces infrastructure administration but can increase dependence on provider-specific services.

In Software as a Service (SaaS), the provider operates the application and much of the underlying stack. The customer still decides what data to place in the service, who may access it, how sharing is configured, whether integrations are trustworthy and whether the service satisfies business and regulatory requirements.

The model is a starting point, not a substitute for contract review. Provider documentation may describe a service boundary, but customers must also inspect service-level agreements, data-processing agreements, incident-notification clauses, audit rights, retention provisions, subcontracting arrangements and exit mechanisms.

2.2 Responsibility versus Accountability

Responsibility means performing an activity. Accountability means being answerable for its outcome. A cloud engineer may be responsible for implementing encryption, while the information owner remains accountable for deciding the required classification and protection level. Accountability should be assigned to a role with authority and resources, not merely to an anonymous team.

A useful governance test is to ask four questions for every important control:

1. Who sets the requirement?
2. Who implements the control?
3. Who monitors its effectiveness?
4. Who accepts the remaining risk if it is not fully achieved?

If these questions cannot be answered, the control is not adequately governed.

3. Governance, Risk, Compliance and Security Operations

These concepts overlap but should not be treated as synonyms.

• Governance establishes direction, authority, priorities and accountability.
• Risk management identifies uncertainty, evaluates its potential effect and selects treatments.
• Compliance demonstrates conformity with laws, regulations, contractual duties and internal requirements.
• Security operations performs day-to-day protection, monitoring, investigation and response.

A governance body may approve a policy requiring multi-factor authentication. Risk management may identify privileged-account compromise as a high-priority threat. Security operations may deploy identity controls and monitor sign-in events. Compliance personnel may collect evidence showing that the requirement is operating effectively.

Governance frameworks such as ISO/IEC 27001, the NIST Cybersecurity Framework, COBIT and the Cloud Security Alliance Cloud Controls Matrix can provide useful reference structures. They are not automatic implementation recipes. An organisation must select controls proportionate to its services, threats, legal obligations and risk appetite.

4. Security Strategy and Business Alignment

A cloud security strategy is a coherent pattern of objectives, principles, capabilities, investments and measures. It should support business and digital-transformation goals rather than operate as an isolated technical document.

For example, a business goal of rapid digital product release may require:

• standardised cloud landing zones;
• reusable secure templates;
• automated testing in continuous integration and delivery pipelines;
• identity federation and central logging;
• pre-approved patterns for common workloads; and
• rapid, risk-based exception handling.

A strategy should answer the following questions:

• Which business services are moving to cloud, and why?
• Which information and processes are most important?
• What threats and regulatory requirements apply?
• Which controls must be centrally standardised?
• Which decisions may product teams make independently?
• What evidence will demonstrate that controls work?
• How will the organisation recover from provider failure or lock-in?

4.1 Strategic Principles

Common principles include:

1. Least privilege: identities receive only the access required for an authorised task.
2. Secure by default: new accounts, networks, storage and services begin in a safe configuration.
3. Zero-trust thinking: access is continuously evaluated rather than automatically trusted because of network location.
4. Automation first: repeatable controls should be implemented through policy-as-code and infrastructure-as-code where feasible.
5. Evidence by design: logging, testing and configuration evidence should be generated as part of normal operation.
6. Resilience: security strategy includes continuity, recovery, dependency management and service exit.
7. Data minimisation: collect, retain and expose only what is necessary.

These principles require interpretation. Least privilege does not mean preventing all productive work; it means designing access that is narrowly scoped, time-limited where possible and reviewed regularly.

5. Policies, Standards, Procedures and Guidelines

A cloud security policy expresses mandatory organisational intent. It might state that sensitive data must be encrypted in transit and at rest, or that production access requires phishing-resistant multi-factor authentication.

A standard specifies a mandatory technical or operational requirement. For example, a standard may require encryption using approved cryptographic services and prohibit public access to storage containing confidential information.

A procedure gives step-by-step instructions, such as how to request privileged access or respond to a suspected exposed credential.

A guideline provides recommended practice where context-dependent judgement is appropriate.

A useful hierarchy is:

Policies should identify scope, ownership, mandatory requirements, exceptions, enforcement, review frequency and consequences of non-compliance. They should be understandable to decision-makers and implementable by technical teams.

6. Roles and Accountability Structures

Cloud governance commonly involves the board or executive committee, chief information security officer, enterprise architects, risk owners, information owners, platform teams, application teams, procurement, legal and internal audit.

A RACI matrix can clarify decision rights:

• Responsible: performs the work.
• Accountable: owns the outcome and approves decisions.
• Consulted: provides specialist input.
• Informed: receives relevant information.

For example, for classifying customer data, the information owner may be accountable; the privacy officer and security architect may be consulted; the application team may be responsible for implementing labels and controls; and the service owner may be informed.

RACI is useful but limited. It may conceal disagreements, create multiple “accountables” or describe a static process in a rapidly changing environment. It should therefore be supported by approval thresholds, escalation routes, service ownership records and periodic review.

A practical operating model often contains:

• a cloud centre of excellence that develops reusable patterns and guidance;
• a platform team that builds landing zones, identity integration, logging and network foundations;
• workload teams that own application-specific risks and controls;
• a security function that defines requirements, monitors threats and supports response; and
• an executive risk forum that resolves material conflicts and accepts residual risk.

7. Risk Appetite, Tolerance and Treatment

Risk appetite is the broad amount and type of risk an organisation is willing to pursue or retain while achieving its objectives. Risk tolerance is the acceptable variation around a specific objective or requirement. Appetite is strategic; tolerance is more operational.

A financial-technology organisation may have very low appetite for unauthorised disclosure of payment data but moderate appetite for limited experimentation in non-production environments. A public research organisation may accept greater confidentiality risk for openly published data but have very low tolerance for integrity failures in research records.

Risk treatment options include:

• Avoid: do not undertake the activity.
• Reduce: implement controls that lower likelihood or impact.
• Share or transfer: allocate some consequences contractually or through insurance, without assuming responsibility disappears.
• Accept: knowingly retain the risk within approved authority.

A common qualitative risk model considers likelihood and impact. If a numerical model is used, an illustrative expected-loss relationship is:

Here, EL is expected loss in currency units per defined period, p is the probability of the event during that period, and L is the financial impact if it occurs. The model assumes that probability and impact can be estimated meaningfully and that the event definition and time period are clear. It is not a prediction of exact loss and should not replace scenario analysis, uncertainty ranges or expert judgement.

For example, if a defined incident has an estimated annual probability of 0.04 and an estimated impact of $250,000, then:

This does not prove that a $10,000 control is worthwhile. The decision must also consider regulatory penalties, safety, reputation, control effectiveness, risk concentration and the organisation’s appetite.

Risk registers should record the risk statement, affected asset or service, causes, consequences, inherent assessment, existing controls, residual assessment, treatment plan, owner, due date and acceptance authority. Risks should be expressed in business terms, such as “loss of customer trust caused by unauthorised disclosure,” rather than only in technical terms such as “misconfigured bucket.”

8. Cloud Guardrails

Guardrails are preventive, detective or corrective constraints that guide cloud use. They enable teams to move quickly within safe boundaries.

Preventive guardrails

These block or restrict unsafe actions. Examples include denying creation of resources in unapproved regions, requiring encryption, preventing public exposure of sensitive storage and restricting use of unmanaged identities.

Detective guardrails

These identify conditions that require attention. Examples include configuration scanning, anomalous-access detection, vulnerability reporting and alerts for disabled logging.

Corrective guardrails

These restore an approved state. Examples include automatically removing public access, quarantining a compromised workload or rotating an exposed credential. Automatic correction must be carefully designed because a technically valid correction can disrupt a critical service.

Effective guardrails have a clear owner, defined scope, documented rationale, measurable state, exception process and tested failure behaviour. They should be risk-based rather than arbitrary. A development sandbox may permit experimental services with spending limits and no sensitive data, whereas a regulated production environment may require stricter controls.

Policy-as-code can express guardrails in machine-evaluable form. Infrastructure-as-code can create standard environments consistently. Neither removes the need for human governance: policies may be incomplete, exceptions may be legitimate, and automated decisions can produce unintended consequences.

9. Assurance, Metrics and Continuous Improvement

Governance requires evidence. Useful evidence includes access reviews, configuration histories, vulnerability remediation records, incident exercises, backup restoration tests, supplier attestations and exception decisions.

Metrics should measure outcomes, not merely activity. Examples include:

• percentage of critical workloads with tested recovery procedures;
• proportion of privileged access using strong authentication;
• time to remediate critical misconfiguration;
• percentage of cloud accounts covered by central logging;
• number and age of open policy exceptions; and
• rate of successful restoration tests.

A metric such as “number of alerts generated” may measure workload rather than security. Metrics should have a defined population, calculation method, reporting period, target and owner. They should also be interpreted carefully: a decrease in detected incidents may indicate improvement, or it may indicate that monitoring has failed.

Assurance combines internal review, independent audit, penetration testing, control testing, provider reports and operational exercises. Provider certifications can provide useful evidence, but they do not demonstrate that the customer configured or used the service correctly.

10. Applied Case: Northstar Health Services

The following is an illustrative case.

Background

Northstar Health Services, a regional healthcare provider, plans to move its patient appointment platform and analytics environment to the cloud. The organisation seeks faster release cycles, elastic analytics and improved disaster recovery. It must protect health information, meet contractual obligations and maintain service availability.

Problem

The application team wants unrestricted ability to create cloud resources. The security team proposes central approval for every change. Procurement has selected a provider but has not completed a review of incident notification, subcontractors, data location or service exit. Responsibility for backups is unclear, and several developers use long-lived administrator credentials.

Analysis

The shared-responsibility analysis identifies that the provider will secure facilities and managed platform components, but Northstar remains accountable for data classification, identity configuration, application security, retention and recovery objectives. The major risks are excessive privilege, accidental public exposure, inadequate recovery testing, unclear contractual assurance and uncontrolled data movement.

The organisation defines a low risk appetite for unauthorised disclosure and interruption of appointment services. It accepts moderate experimentation risk in isolated development environments, provided that real patient information is prohibited.

Approach and solution

Northstar establishes an executive cloud risk forum and assigns service ownership. A platform team creates separate development, test and production accounts under central management. Guardrails require approved regions, central logging, encryption, strong authentication for privileged users, network segmentation and denial of public storage access.

Developers receive self-service templates for approved architectures. High-risk exceptions require approval from the information owner and security risk officer; emergency exceptions expire automatically unless renewed. Backup responsibility is divided explicitly: the platform team provides backup mechanisms, while the application owner defines recovery objectives and performs restoration tests.

The contract requires timely incident notification, defined support obligations, audit evidence, data-processing terms and an exit plan. Identity federation replaces long-lived individual administrator credentials with role-based and time-limited access. Security metrics are reported monthly to the risk forum.

Outcome

Delivery speed improves because teams use approved patterns rather than waiting for bespoke design reviews. Security improves through central visibility and preventive controls. The organisation also discovers that a backup policy alone is insufficient: restoration testing reveals an application dependency that had not been included in the recovery design.

Learning points

1. Shared responsibility must be mapped to actual services and configurations.
2. Accountability for data and business outcomes remains with the customer.
3. Guardrails can support self-service rather than merely restrict it.
4. Contracts and exit planning are security concerns, not only procurement concerns.
5. Recovery capability must be demonstrated through testing.

11. Challenges and Limitations

Cloud governance faces several persistent difficulties. First, provider services change rapidly, so static policies may become inaccurate. Second, multi-cloud environments create inconsistent terminology, control coverage and evidence. Third, excessive centralisation can slow delivery and encourage shadow IT. Fourth, automated remediation can create availability problems if context is ignored. Fifth, compliance evidence may create a false sense of security when controls are documented but ineffective.

There are also ethical issues. Monitoring should be proportionate, transparent and limited to legitimate security purposes. Automated risk scoring should be reviewed for bias and error. Staff should not be blamed for governance failures caused by unclear ownership or unrealistic processes. Data sovereignty and cross-border processing should be assessed with legal and societal consequences in mind.

Artificial intelligence can assist with configuration analysis, anomaly detection, policy translation and incident triage. However, AI-generated recommendations require human validation, especially where they affect access, regulated data or production availability. Sensitive organisational information should not be submitted to an AI service without approved privacy and security controls.

12. Best-Practice Implementation Sequence

A practical implementation sequence is:

1. Inventory cloud accounts, services, workloads, data and suppliers.
2. Identify business owners, information owners and accountable executives.
3. Map provider and customer responsibilities for each service.
4. Define classification, risk appetite, regulatory requirements and security principles.
5. Establish a governed landing zone with identity, logging, network and account foundations.
6. Publish policies, standards, approved patterns and exception procedures.
7. Implement high-value preventive and detective guardrails.
8. Integrate security into development and deployment workflows.
9. Test incident response, backup restoration and provider failure scenarios.
10. Measure outcomes, review exceptions and improve controls continuously.

This sequence should be adapted to organisational context. A small organisation may use a managed security provider, while a large enterprise may require federated governance across business units. In both cases, clarity of accountability is essential.

Chapter Summary

Cloud security is governed through a shared-responsibility model in which the CSP and customer protect different parts of the service environment. The customer remains accountable for business use, data, identity, configuration and compliance even when infrastructure is outsourced. Responsibility varies across IaaS, PaaS and SaaS and must be confirmed through technical documentation and contracts.

Governance establishes direction, decision rights and accountability; risk management evaluates uncertainty and treatment options; compliance provides assurance; and security operations performs daily protection and response. A successful security strategy aligns these activities with business and digital-transformation objectives.

Policies express mandatory intent, standards define minimum conditions, procedures describe execution and guidelines support judgement. Risk appetite and tolerance determine which cloud activities may be accepted, reduced, transferred or avoided. Guardrails—preventive, detective and corrective—enable controlled self-service when they are measurable, owned and supported by an exception process.

Effective governance depends on evidence, meaningful metrics, recovery testing, supplier assurance and continuous improvement. The strongest cloud operating models combine central standards with delegated execution, allowing innovation within clearly understood boundaries.

Key Terms

Shared responsibility: Division of security duties between a CSP and its customer.

Cloud service provider: Organisation that delivers cloud computing services.

IaaS: Cloud model providing virtualised infrastructure resources.

PaaS: Cloud model providing a managed application platform.

SaaS: Cloud model providing a complete managed software service.

Governance: Direction, oversight, authority and accountability for organisational activity.

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

Risk tolerance: Acceptable variation around a defined objective or requirement.

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

Risk owner: Person accountable for managing a defined risk.

Information owner: Person accountable for classification, use and protection requirements for information.

Guardrail: Constraint or control that guides cloud activity toward an approved state.

Landing zone: Governed foundational cloud environment containing standard identity, network, logging and account controls.

Policy-as-code: Machine-readable representation of policy requirements.

RACI: Matrix identifying who is Responsible, Accountable, Consulted and Informed.

Least privilege: Provision of only the access necessary for an authorised task.

Control: Measure designed to prevent, detect, correct or recover from an adverse event.

Assurance: Evidence-based confidence that governance and controls are designed and operating effectively.

Expected loss: Estimated probability-weighted impact for a defined event and period.

Exception: Authorised deviation from a policy or standard, normally subject to justification, approval and expiry.

Review Questions

Short Answer Questions

1. What is meant by the shared-responsibility model in cloud computing?
2. How does customer responsibility differ between IaaS and SaaS?
3. Distinguish a policy from a procedure.
4. Define risk appetite and risk tolerance.
5. What is the purpose of a cloud guardrail?

Long Answer Questions

1. Explain how governance, risk management, compliance and security operations interact in a cloud operating model.
2. Compare security responsibilities in IaaS, PaaS and SaaS, including the importance of configuration and contracts.
3. Discuss how a cloud security strategy can support digital transformation rather than obstruct it.
4. Explain the role of accountability, RACI structures and risk ownership in cloud governance.
5. Evaluate the advantages and limitations of preventive, detective and corrective guardrails.

Analytical / Application Questions

1. An organisation allows developers to create public storage resources containing customer data. Analyse the governance, responsibility and guardrail failures, and propose a remediation plan.
2. A business has an estimated 0.02 annual probability of a defined cloud incident with an estimated impact of $500,000. Calculate the illustrative expected loss using EL = p × L, then explain why the result alone cannot determine whether a control should be purchased.
3. Design a governance model for a regulated organisation adopting SaaS for human-resources data. Identify accountable roles, required contractual checks, minimum guardrails, evidence sources and an exception process.

Multiple Choice Questions with Answers

Question 1

Which responsibility normally remains with the customer in all major cloud service models?

A. Physical security of the provider’s data centre

B. Hypervisor patching

C. Data classification and lawful use

D. Replacement of failed physical disks

Correct Answer: C. Data classification and lawful use

Question 2

In which service model does the customer generally manage the operating system?

A. IaaS

B. PaaS

C. SaaS

D. None of these

Correct Answer: A. IaaS

Question 3

What is the primary purpose of governance?

A. To eliminate every possible risk

B. To establish direction, authority and accountability

C. To replace security operations

D. To guarantee that incidents never occur

Correct Answer: B. To establish direction, authority and accountability

Question 4

Which document normally defines mandatory organisational intent?

A. Guideline

B. Procedure

C. Policy

D. Technical comment

Correct Answer: C. Policy

Question 5

An organisation’s broad willingness to pursue or retain risk is its:

A. Risk appetite

B. Risk register

C. Control objective

D. Recovery point

Correct Answer: A. Risk appetite

Question 6

Which is a preventive guardrail?

A. A report of last month’s incidents

B. A rule denying unapproved public storage access

C. A post-incident lessons-learned meeting

D. A restoration test after an outage

Correct Answer: B. A rule denying unapproved public storage access

Question 7

A developer implements encryption, while the information owner approves the required classification. Which concept best explains this distinction?

A. Responsibility and accountability

B. Availability and elasticity

C. Avoidance and transfer

D. Detection and correction

Correct Answer: A. Responsibility and accountability

Question 8

If p = 0.02 and L = $500,000, what is the illustrative expected loss?

A. $1,000

B. $10,000

C. $25,000

D. $100,000

Correct Answer: B. $10,000

Question 9

Which statement about provider certification is most accurate?

A. It proves the customer configured the service correctly.

B. It removes the customer’s legal responsibilities.

C. It can provide useful evidence but does not replace customer assurance.

D. It guarantees that no security incident can occur.

Correct Answer: C. It can provide useful evidence but does not replace customer assurance.

Question 10

What is a key purpose of an exception process?

A. To permit permanent bypassing of all controls

B. To document and authorise justified deviations with oversight

C. To transfer all risk to the cloud provider

D. To prevent any use of self-service cloud resources

Correct Answer: B. To document and authorise justified deviations with oversight