Cloud Risk Management Frameworks

Introduction and context

Cloud computing changes the location, ownership and operating model of information technology risk. An organisation may no longer own the physical servers, operate the hypervisor or control every administrator who can affect its data. Nevertheless, it remains accountable for business outcomes, legal obligations, information protection and service resilience. Cloud risk management therefore provides a structured way to identify uncertainty, assess its possible effects, select proportionate responses and monitor changing conditions.

This chapter examines five complementary instruments: ISO 31000, ISO/IEC 27001, the NIST Cybersecurity Framework (CSF), the NIST Risk Management Framework (RMF), and the Cloud Security Alliance Cloud Controls Matrix (CSA CCM). It also explains how to construct and use a cloud risk register. These frameworks should not be treated as competing checklists. ISO 31000 supplies general risk-management principles; ISO/IEC 27001 provides an information-security management-system model; NIST CSF communicates cybersecurity outcomes; NIST RMF structures system-level security and privacy decisions; and CSA CCM translates cloud-specific concerns into control domains.

Learning objectives

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

1. Explain cloud risk, threat, vulnerability, impact, likelihood and control.
2. Distinguish qualitative and quantitative risk analysis.
3. Apply risk identification, treatment, acceptance, transfer and monitoring.
4. Relate ISO 31000, ISO/IEC 27001, NIST CSF, NIST RMF and CSA CCM.
5. Construct a useful cloud risk register and interpret its contents.
6. Evaluate governance, supplier, regulatory and ethical implications of cloud risk decisions.

1. Risk in a cloud operating model

Risk is the effect of uncertainty on objectives. The effect may be negative or positive, although security management usually concentrates on adverse effects. A cloud risk statement should connect a cause to an event and then to a consequence. For example: “Because a storage bucket policy is publicly readable, unauthorised parties may retrieve customer records, causing regulatory exposure and loss of trust.”

Important terms include:

• Asset: something of value, such as data, an application, an identity, a cryptographic key or a service.
• Threat: a circumstance or actor capable of causing harm, such as a criminal group, malicious insider, software defect or natural hazard.
• Vulnerability: a weakness that can be exploited or triggered.
• Likelihood: the chance that a specified event will occur within a stated period and under stated conditions.
• Impact: the magnitude of consequences for confidentiality, integrity, availability, safety, finance, compliance or reputation.
• Control: a measure that modifies risk. Controls may be preventive, detective, corrective, deterrent or compensating.
• Inherent risk: risk before considering controls.
• Residual risk: risk remaining after controls and other treatments.
• Risk owner: the person accountable for ensuring that a risk is assessed, treated and monitored.
• Control owner: the person responsible for implementing and operating a particular control.

Cloud risk is shaped by the shared-responsibility model. The provider normally secures facilities, physical infrastructure and core managed services, while the customer remains responsible for matters such as identity configuration, data classification, endpoint security and workload settings. Responsibility varies by service model. In infrastructure as a service, the customer manages more of the operating system and application stack; in software as a service, the provider manages more technical layers, but the customer still governs users, data, authorisation and business use.

A common error is to interpret provider certification as proof that the customer is secure. A provider’s ISO/IEC 27001 certificate or SOC report describes a defined scope and control environment. It does not validate every customer configuration, workload or business process.

2. Governance principles for cloud risk

Effective risk management is integrated with organisational governance rather than delegated entirely to a security department. Senior management establishes risk appetite, approves resources and accepts significant residual risk. The board or a designated risk committee provides oversight. Security, privacy, legal, procurement, architecture, operations and business owners contribute different evidence and judgments.

ISO 31000 presents principles and a process rather than a cloud-specific certification scheme. Its central ideas are integration, a structured and comprehensive approach, customisation, inclusion of relevant stakeholders, use of the best available information, consideration of human and cultural factors, continual improvement and attention to changing circumstances. The process usually includes communication and consultation, scope/context/criteria, risk assessment, risk treatment, recording/reporting, and monitoring/review.

Risk criteria must be established before assessment. Criteria can define rating scales, materiality thresholds, escalation rules, risk appetite and acceptance authority. For example, an organisation may declare that any risk involving regulated health data and a high likelihood of unauthorised disclosure requires executive approval and cannot be accepted by a project manager.

Risk appetite expresses the amount and type of risk an organisation is willing to pursue or retain. Risk tolerance defines acceptable variation around objectives. These are not identical to a low numerical score: a low-probability event involving catastrophic safety consequences may require treatment despite a modest calculated score.

3. ISO/IEC 27001 and the information-security management system

ISO/IEC 27001 specifies requirements for an information-security management system (ISMS). An ISMS is a management system through which an organisation establishes policy, assesses information-security risks, selects controls, assigns responsibility, measures performance and improves continuously.

A cloud ISMS typically includes:

1. Defining organisational and technological scope, including cloud services and interfaces.
2. Understanding interested parties, contractual requirements and applicable law.
3. Establishing information-security objectives and risk criteria.
4. Performing repeatable risk assessment and risk treatment.
5. Selecting applicable controls and documenting the rationale in a Statement of Applicability.
6. Operating controls, training personnel and retaining evidence.
7. Conducting internal audits and management reviews.
8. Correcting nonconformities and improving the system.

The Statement of Applicability should not be a superficial list of controls. For each relevant control, the organisation should explain whether it is applicable, its implementation status and its justification. Cloud contracts, provider assurance reports, configuration baselines, access reviews, incident records and backup tests may provide supporting evidence.

ISO/IEC 27001 is risk-based and technology-neutral. It can govern public, private, hybrid or multicloud environments, but it does not prescribe one architecture. Organisations must translate its requirements into practical cloud policies, such as privileged-access management, key-management responsibilities, logging retention, workload segregation and exit planning.

4. NIST Cybersecurity Framework

The NIST CSF is a flexible framework for communicating and improving cybersecurity risk. Its current structure is organised around six Functions:

The CSF can be used to create a Current Profile describing present outcomes and a Target Profile describing desired outcomes. A gap analysis then identifies priorities. Profiles are useful for communication because they express what should be achieved without requiring all stakeholders to understand technical implementation details.

For example, a target outcome may require that all privileged cloud actions be attributable to an individual, strongly authenticated, logged and reviewed. The implementation might involve central identity federation, phishing-resistant authentication, just-in-time privilege, immutable logging and alerting. The framework outcome is more stable than any particular product.

5. NIST Risk Management Framework

NIST RMF is a system-oriented process for managing security and privacy risk. Its commonly used steps are:

1. Prepare: establish organisational and system context, risk assumptions, dependencies and priorities.
2. Categorize: determine the potential impact of loss of confidentiality, integrity and availability.
3. Select: choose and tailor controls based on risk, requirements and system context.
4. Implement: deploy controls and document how they operate.
5. Assess: determine whether controls are implemented correctly, operating as intended and producing the desired outcomes.
6. Authorize: an authorizing official accepts or rejects the residual risk and permits operation.
7. Monitor: continuously track changes, control effectiveness, vulnerabilities, incidents and risk.

Categorization should reflect the adverse effect on organisational operations, assets, individuals and other organisations. A system can have different impact levels for confidentiality, integrity and availability. For example, a public information website may have low confidentiality impact but high availability impact during a critical public event.

RMF emphasises explicit accountability. The system owner, authorizing official, security officer, privacy officer, control providers and independent assessors have different responsibilities. This separation helps prevent the same team from defining, implementing and approving its own controls without challenge.

6. CSA Cloud Controls Matrix

The CSA CCM is a cloud-focused control framework that maps security practices to domains such as governance, risk management, identity and access management, application and interface security, data security and privacy, logging and monitoring, infrastructure and virtualisation security, interoperability and portability, and incident management.

Its value is contextual specificity. A general information-security framework may require access control, while the CCM encourages examination of cloud concerns such as tenant isolation, administrative interfaces, virtual-machine images, provider chains, portability, deletion and encryption responsibilities. CCM mappings can support procurement questionnaires, architecture reviews, control crosswalks and supplier assessments.

The CCM should be used with evidence. A supplier’s answer of “implemented” is insufficient without scope, responsible party, assurance period, exceptions, technical descriptions and independent evidence. The customer should also identify controls that remain customer-managed.

7. Risk identification and assessment

Risk identification begins with scope and asset understanding. Useful sources include data-flow diagrams, cloud-account inventories, identity inventories, threat intelligence, vulnerability scanning, penetration testing, incident history, provider documentation, contract reviews and workshops with system owners.

A practical cloud workshop can ask:

• What data and services are present, and how are they classified?
• Which identities, APIs and trust relationships can reach them?
• What happens if the provider, region, account or key becomes unavailable?
• Which provider or subcontractor dependencies are material?
• How would the organisation detect misuse and prove what happened?
• Can the organisation recover, migrate or securely delete its information?

Qualitative analysis

Qualitative analysis uses categories such as Very Low, Low, Medium, High and Very High. A simple risk matrix may combine likelihood and impact, but the scale must be defined. “High likelihood” should specify a period or frequency, and “high impact” should specify consequences.

A five-by-five matrix can be useful for prioritisation, but it is ordinal rather than a precise measurement. The difference between High and Medium is not necessarily equal to the difference between Medium and Low. Therefore, a matrix should support judgment, not disguise uncertainty as exact science.

Quantitative analysis

Where credible data exist, expected annual loss can support economic comparison:

Here, SLE is the single-loss expectancy in currency per event, and ARO is the annual rate of occurrence in events per year. ALE is the expected annual loss in currency per year. The model assumes that loss events can be represented by a meaningful average and that the estimate is appropriate for comparison. It does not predict the exact loss in a particular year.

If an incident would cost £120,000 and is estimated to occur 0.25 times per year, then:

If a proposed control costs £18,000 annually and reduces the estimated ALE to £7,000, the estimated annual loss reduction is £23,000. A simple financial comparison gives a net expected benefit of £5,000 per year before implementation risk, indirect benefits, residual uncertainty and non-financial obligations. The calculation must not be used to justify violating law or abandoning essential safety controls.

A more complete model may use scenarios rather than one average. If scenarios i have probabilities p_i and losses L_i, expected loss is:

The assumptions are that probabilities are non-negative, sum to 1 across the defined scenarios, and losses are measured on a consistent basis. Rare, severe events and dependencies may make estimates highly uncertain; sensitivity analysis should therefore accompany a numerical result.

8. Risk treatment decisions

Risk treatment selects and implements measures that change risk. The principal options are:

• Avoid: discontinue the risky activity, data use or architecture.
• Reduce or modify: lower likelihood, impact or both through controls.
• Share or transfer: allocate financial or operational consequences through insurance, contracts, outsourcing or service agreements. Accountability is rarely transferred completely.
• Accept or retain: consciously retain residual risk within approved criteria.

Acceptance must be explicit, time-bounded where appropriate, assigned to an authorised person and supported by a rationale. “No action” is not automatically acceptance. A risk may be tolerated temporarily while a funded treatment is implemented, but the register should show owner, due date, interim safeguards and escalation route.

Controls should be selected according to risk and assurance needs. Examples include phishing-resistant multifactor authentication, least privilege, network segmentation, encryption, customer-managed keys, secure configuration baselines, backup immutability, vulnerability management, provider-independent logging, incident playbooks and tested recovery procedures.

Risk transfer requires careful contract analysis. Service-level agreements, liability clauses, audit rights, breach notification periods, data-location terms, subcontractor controls and exit assistance influence risk, but contractual language cannot guarantee technical performance. Insurance also has exclusions, deductibles and conditions.

9. The cloud risk register

A risk register is a living governance record, not a static spreadsheet created for an audit. A useful record contains enough information to support decisions and monitoring.

A register should distinguish a risk from an issue. A risk is uncertain; an issue has already occurred or is currently present. A publicly exposed database found during a scan may be an issue requiring immediate containment, while the possibility of future exposure is a risk.

10. Continuous monitoring and assurance

Cloud environments change rapidly through infrastructure-as-code, autoscaling, new identities, provider feature changes and continuous deployment. Annual assessment alone is inadequate. Monitoring should combine automated technical signals with management review.

Useful indicators include the percentage of privileged accounts using strong authentication, unresolved critical vulnerabilities, public storage resources, backup restoration success, mean time to detect and respond, logging coverage, policy exceptions, provider incidents and overdue treatment actions. Indicators need thresholds, owners and response procedures. A metric without a decision rule is merely a number.

Continuous monitoring should consider configuration drift, identity changes, vulnerabilities, threat intelligence, control failures, service health, supplier posture and regulatory developments. Changes that exceed predefined thresholds should trigger reassessment, reauthorisation or escalation.

Assurance may include internal audit, independent assessment, penetration testing, control self-assessment, provider reports and evidence sampling. Evidence should demonstrate operation over time rather than only the existence of a policy.

11. Illustrative case: migration of a health-support platform

Background. A fictional community health organisation plans to move its appointment and consultation platform to a public cloud. The platform stores appointment details and selected clinical notes. It requires high availability and exchanges data with a laboratory service.

Problem. The project team initially assumes that the provider’s security certification eliminates most risk. A design review identifies a broad administrator role, unencrypted development data, unclear laboratory credentials, incomplete audit logging and no tested exit procedure.

Analysis. The team maps assets, data flows and responsibilities. Under an ISO 31000 process, it defines risk criteria and consults clinical, legal, procurement and technical stakeholders. ISO/IEC 27001 requirements guide governance, risk treatment and evidence. The NIST CSF Current Profile shows weaknesses in Identify, Protect and Detect. RMF-style categorization identifies high confidentiality and availability consequences for the consultation service. CSA CCM domains focus attention on identity, data security, logging, portability and supplier relationships.

The register records a risk that excessive administrative privilege could enable unauthorised disclosure or alteration of records. Inherent likelihood is rated High and impact Very High. Another risk concerns regional service interruption, with Medium likelihood and High impact. Quantitative loss estimates are used only as supporting evidence because patient welfare and legal duties cannot be reduced to money.

Approach and solution. The organisation removes standing administrator access, introduces federated phishing-resistant authentication and just-in-time privilege, separates production from development, tokenises test data, encrypts data in transit and at rest, centralises tamper-resistant logs, and tests restoration. The laboratory integration receives a dedicated identity with narrowly defined permissions. Contract negotiations add breach notification, subcontractor disclosure, audit evidence, deletion and exit-assistance provisions. The authorizing official accepts only the documented residual risk after reviewing assessment evidence.

Outcome. The service enters production with a monitored risk register, defined indicators and a quarterly governance review. Automated policy checks detect public exposure and privilege drift. A recovery exercise reveals that a dependency was omitted from the original plan; the register is updated and the recovery design corrected.

Learning points. Provider assurance is valuable but does not replace customer governance. Risk decisions require both technical evidence and business accountability. Recovery, portability and supplier dependencies must be assessed before migration, not after an incident.

12. Limitations, ethics and contemporary developments

Frameworks can create false confidence when organisations measure documentation rather than outcomes. Control catalogues may encourage checkbox compliance, duplicate evidence requests or excessive controls that obstruct legitimate work. Risk ratings can also reflect seniority or optimism instead of evidence. Independent challenge, transparent assumptions and periodic calibration reduce these weaknesses.

Ethically, cloud risk decisions should consider affected individuals, not only the organisation’s financial loss. Excessive monitoring may threaten privacy; automated threat detection may produce discriminatory or unjustified decisions; and opaque provider algorithms can make accountability difficult. Data minimisation, purpose limitation, proportionality, human review and clear retention rules are important safeguards. Regulatory requirements may include privacy, breach reporting, financial resilience, records management and sector-specific obligations. Legal advice is required because obligations depend on jurisdiction and processing activity.

Artificial intelligence can assist risk analysis by grouping findings, identifying anomalous configurations and summarising evidence. It should not independently accept high-impact risk or make unreviewed decisions about people. AI outputs may be incomplete, biased or based on confidential data. Human accountability, traceability, access control and validation remain necessary.

Contemporary practice increasingly emphasises zero-trust architecture, software supply-chain security, confidential computing, infrastructure-as-code policy enforcement, cloud detection and response, operational resilience, data sovereignty and cryptographic agility. These developments do not eliminate the need for the core cycle: establish context, identify risk, analyse it, treat it, accept residual exposure appropriately and monitor change.

Best-practice implementation sequence

A practical implementation can proceed as follows:

1. Establish executive sponsorship, scope, risk appetite and acceptance authority.
2. Inventory cloud accounts, services, identities, data and critical dependencies.
3. Define risk criteria and a consistent risk-statement format.
4. Identify threats and vulnerabilities using architecture reviews, testing and stakeholder workshops.
5. Assess inherent risk qualitatively, adding quantitative analysis where evidence supports it.
6. Map relevant requirements to ISO/IEC 27001, NIST CSF, NIST RMF and CSA CCM without duplicating controls unnecessarily.
7. Select treatments, assign owners, set deadlines and document residual risk.
8. Verify implementation through testing and independent evidence.
9. Obtain explicit authorisation for material residual risks.
10. Monitor indicators, reassess changes and improve after incidents and exercises.

Chapter Summary

Cloud risk management is a continuous governance discipline for dealing with uncertainty in shared, dynamic and supplier-dependent environments. ISO 31000 provides general principles and process; ISO/IEC 27001 provides an ISMS; NIST CSF organises cybersecurity outcomes; NIST RMF structures system categorization, control selection, assessment and authorization; and CSA CCM adds cloud-specific control detail. Risk assessment requires clear assets, threats, vulnerabilities, likelihood, impact and criteria. Qualitative ratings support prioritisation, while quantitative expected-loss models can support comparison when assumptions and data are credible. Treatment may avoid, reduce, share or accept risk, but accountability remains with authorised decision-makers. A risk register, supported by evidence and continuous monitoring, connects analysis to action. Effective practice integrates technical controls, contracts, privacy, regulation, ethics, resilience and business objectives.

Key Terms

Risk: Effect of uncertainty on objectives.

Threat: Circumstance or actor capable of causing harm.

Vulnerability: Weakness that may be exploited or triggered.

Likelihood: Chance that a specified event will occur in a defined period.

Impact: Magnitude of consequences resulting from an event.

Control: Measure that modifies risk.

Inherent risk: Risk before controls or treatments are considered.

Residual risk: Risk remaining after treatment.

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

Risk owner: Person accountable for managing a risk.

Risk register: Structured record of risks, controls, owners, treatments and status.

ISMS: Information-security management system.

ISO 31000: International guidance for principles and processes of risk management.

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

NIST CSF: Framework for communicating and improving cybersecurity outcomes.

NIST RMF: Structured process for managing system security and privacy risk.

CSA CCM: Cloud-focused control framework and matrix.

ALE: Expected annual loss, commonly estimated as SLE × ARO.

Risk acceptance: Explicit decision to retain residual risk.

Continuous monitoring: Ongoing observation and reassessment of risk and control effectiveness.

Review Questions

Short Answer Questions

1. What is the difference between inherent risk and residual risk?
2. Why does a cloud provider’s certification not prove that a customer workload is secure?
3. Name the six Functions of the NIST Cybersecurity Framework.
4. What information should a risk statement connect?
5. What is the purpose of a risk register?

Long Answer Questions

1. Compare the purposes and strengths of ISO 31000, ISO/IEC 27001, NIST CSF, NIST RMF and CSA CCM.
2. Explain how shared responsibility affects cloud risk ownership and control selection.
3. Describe a complete risk-treatment process from identification through acceptance and monitoring.
4. Discuss the benefits and limitations of qualitative and quantitative risk analysis.
5. Explain how governance, contracts, privacy and resilience should be integrated into cloud risk management.

Analytical / Application Questions

1. A cloud storage service contains regulated records and is discovered to permit anonymous read access. Construct a risk statement, identify immediate controls, and specify who should accept any residual risk.
2. A proposed control costs £18,000 per year and reduces estimated annual loss from £30,000 to £7,000. Calculate the annual loss reduction and discuss why the result alone cannot determine the decision.
3. Design five risk-register fields and three monitoring indicators for a critical cloud-based healthcare application. Explain the escalation rule for each indicator.

Multiple Choice Questions with Answers

Question 1

Which framework provides general principles and a process for managing risk across organisational contexts?

A. ISO 31000

B. CSA CCM

C. NIST CSF

D. NIST RMF

Correct Answer: A. ISO 31000

Question 2

Which NIST RMF step involves choosing and tailoring security and privacy controls?

A. Categorize

B. Select

C. Authorize

D. Monitor

Correct Answer: B. Select

Question 3

What is the main purpose of a Statement of Applicability in an ISO/IEC 27001 ISMS?

A. To list cloud-provider invoices

B. To document applicable controls, implementation status and justification

C. To replace risk assessment

D. To calculate annual loss

Correct Answer: B. To document applicable controls, implementation status and justification

Question 4

A loss per incident is £80,000 and the annual rate of occurrence is 0.5. What is the estimated annual loss?

A. £40,000

B. £80,000

C. £160,000

D. £400,000

Correct Answer: A. £40,000

Question 5

Which treatment completely stops an organisation from performing the risky activity?

A. Transfer

B. Accept

C. Avoid

D. Monitor

Correct Answer: C. Avoid

Question 6

Which NIST CSF Function includes anomaly detection and event analysis?

A. Protect

B. Detect

C. Respond

D. Recover

Correct Answer: B. Detect

Question 7

Why is a risk matrix not normally a precise measurement scale?

A. It cannot contain impact ratings

B. Its ordinal categories do not guarantee equal numerical intervals

C. It can only be used for financial risks

D. It requires no defined criteria

Correct Answer: B. Its ordinal categories do not guarantee equal numerical intervals

Question 8

Which framework is specifically focused on cloud control domains such as tenant isolation, portability and virtualisation security?

A. CSA CCM

B. ISO 31000

C. NIST CSF

D. ISO 9001

Correct Answer: A. CSA CCM

Question 9

Who is generally accountable for ensuring that a risk is assessed, treated and monitored?

A. Risk owner

B. Control auditor only

C. Cloud end user only

D. Penetration tester

Correct Answer: A. Risk owner

Question 10

A control reduces estimated annual loss from £30,000 to £7,000 and costs £18,000 annually. Before considering other factors, what is the estimated net annual benefit?

A. £5,000

B. £7,000

C. £18,000

D. £23,000

Correct Answer: A. £5,000