Cyber Risk Management and Compliance Frameworks

Introduction

Cybersecurity is not achieved by purchasing a collection of technical products. It is achieved by making informed decisions about what must be protected, from whom, against which events, and at what cost. Cyber risk management provides the systematic process for making those decisions. Compliance frameworks provide structured ways to design, operate, assess and improve security controls.

For a modern organisation, risk management connects business objectives with cybersecurity practice. A hospital may prioritise patient safety and availability of clinical systems; a bank may prioritise transaction integrity and confidentiality; a public agency may prioritise lawful processing and continuity of essential services. The same technical vulnerability can therefore represent different levels of risk in different contexts.

This chapter explains how to conduct asset, threat, vulnerability, likelihood, impact and control assessments. It then relates risk treatment to ISO/IEC 27001, ISO/IEC 27002, the NIST Cybersecurity Framework (CSF), and related governance and compliance frameworks.

Learning Objectives

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

1. Identify and classify information assets and their business owners.
2. Distinguish threats, vulnerabilities, events, consequences and risks.
3. Perform qualitative and basic quantitative risk assessments.
4. Evaluate existing and proposed security controls.
5. Select suitable risk treatment options and document residual risk.
6. Explain the relationship between ISO/IEC 27001, ISO/IEC 27002, NIST CSF and other frameworks.
7. Recognise legal, ethical, governance and assurance implications of cyber risk decisions.

1. Foundations of Cyber Risk Management

1.1 Risk in an information-security context

Risk is the effect of uncertainty on objectives. In cybersecurity, risk commonly arises when a threat can exploit a vulnerability and produce a harmful consequence. A useful conceptual model is:

Asset → Threat → Vulnerability → Risk event → Impact

An asset is anything valuable to an organisation, including information, systems, people, services, facilities, reputation and intellectual property. A threat is a potential cause of an unwanted incident, such as ransomware, fraud, malicious insiders, equipment failure or a natural disaster. A vulnerability is a weakness that could be exploited or triggered. A risk event is the occurrence that creates harm, while impact is the resulting effect on confidentiality, integrity, availability, legal compliance, finances, safety or reputation.

Risk is not the same as a vulnerability. A vulnerability may exist without being exploited, and a threat may exist without having a relevant path to an asset. Risk requires consideration of both probability and consequence.

1.2 The CIA triad and broader objectives

The traditional security objectives are:

• Confidentiality: information is available only to authorised subjects.
• Integrity: information and systems remain accurate, complete and trustworthy.
• Availability: authorised users can access systems and information when needed.

Contemporary risk assessments often add authenticity, accountability, privacy, resilience and safety. For example, integrity failures in an industrial control system may create physical danger, while confidentiality failures involving health records may cause legal and personal harm.

1.3 Risk appetite and risk tolerance

Risk appetite is the amount and type of risk an organisation is willing to pursue or retain in support of its objectives. Risk tolerance specifies acceptable variation around a target. A financial institution may have very low tolerance for unauthorised payment transactions but a higher tolerance for a short interruption to an internal information portal.

Risk appetite should be established by governance bodies, not inferred solely by technical staff. It influences prioritisation, funding, escalation and acceptance decisions.

2. The Risk Assessment Process

A practical risk assessment normally follows these stages:

1. Establish context and assessment criteria.
2. Identify assets, processes and dependencies.
3. Identify threats and vulnerabilities.
4. Analyse likelihood and impact.
5. Evaluate risk against acceptance criteria.
6. Select treatment options.
7. Record decisions and assign ownership.
8. Monitor, review and communicate results.

This process is iterative. New technologies, suppliers, laws, business processes and threat intelligence may change the assessment.

2.1 Establishing context

Before scoring risks, an organisation should define:

• business objectives and critical services;
• legal, regulatory and contractual obligations;
• assessment scope and boundaries;
• risk scales and acceptance criteria;
• relevant stakeholders and decision-makers;
• assumptions, exclusions and time horizon.

A narrow technical assessment may examine a web application, whereas an enterprise assessment may include people, suppliers, cloud services, physical locations and business continuity.

2.2 Asset identification and valuation

Asset identification should begin with business processes rather than only with hardware inventories. A payroll process, for example, depends on employee records, payroll software, identity services, network connectivity, administrators, cloud providers and backup systems.

An asset register should record at least:

Asset valuation should consider direct and indirect effects. A customer database may have high confidentiality value, while a production-control system may have exceptionally high availability and safety value. Classification labels such as public, internal, confidential and restricted are useful, but labels must be supported by handling rules.

2.3 Threat assessment

Threat assessment asks what could cause harm and how. Threat sources may include:

• cybercriminal groups seeking money;
• nation-state or politically motivated actors;
• insiders, whether malicious or negligent;
• competitors or fraudsters;
• suppliers and service providers;
• natural hazards and physical events;
• software defects and operational mistakes.

Threat intelligence should be interpreted in context. The existence of a threat in the wider internet does not automatically mean that it is relevant to a particular organisation. Relevance depends on exposure, motivation, capability, opportunity and existing controls.

2.4 Vulnerability assessment

Vulnerabilities include unpatched software, weak authentication, excessive privileges, insecure configurations, inadequate monitoring, poor processes, insufficient training and weak supplier governance. Technical scanning is valuable, but it does not replace human and process assessment.

A vulnerability assessment should consider exploitability, exposure, required privileges, detectability, affected assets and the effectiveness of compensating controls. A critical vulnerability on an isolated, well-monitored system may present less immediate risk than a moderate vulnerability on an internet-facing identity service.

3. Likelihood, Impact and Risk Analysis

3.1 Qualitative analysis

Many organisations use a matrix with ordinal categories such as Low, Medium and High. A five-level scale can provide more differentiation:

A simple inherent-risk score is calculated as:

Here, R is the risk score, L is the likelihood score and I is the impact score. The equation is a prioritisation convention, not a universal law of probability. It is applicable when the scales are defined consistently and decision-makers understand that ordinal scores do not necessarily have equal numerical intervals.

For example, if credential theft is assessed as likelihood 4 and impact 5:

If the organisation defines scores 15–25 as high, the risk is high. The result does not mean that there is a 20 percent probability of loss.

3.2 Quantitative analysis

Where reliable data exist, annualised loss models can support financial decisions. A basic model is:

ALE is annualised loss expectancy, SLE is single-loss expectancy, and ARO is annual rate of occurrence. SLE may be estimated as:

AV is asset value and EF is exposure factor, expressed as a proportion from 0 to 1. These models assume that the estimates are meaningful and that losses can reasonably be represented in financial terms. They should not be used to create false precision.

Worked example. An incident affecting an online service is estimated to cause a direct and indirect loss of $80,000 per occurrence. If the expected frequency is 0.25 occurrences per year:

A proposed control costing $12,000 annually may appear economically attractive, but the decision must also consider implementation risk, legal duties, safety, reputation, dependencies and uncertainty. Expected loss is not the only decision criterion.

3.3 Inherent and residual risk

Inherent risk is the risk before considering controls. Residual risk is the risk remaining after controls are applied. A control may reduce likelihood, impact, or both. For example, multi-factor authentication reduces the likelihood of account takeover, while tested backups reduce the impact of ransomware by improving recovery.

Residual risk should be explicitly accepted, transferred, avoided or reduced. It should never disappear merely because a control has been planned. A control is relevant to residual risk only when it is implemented, appropriately designed and operating effectively.

4. Control Assessment

4.1 What is a control?

A control is a measure that modifies risk. Controls may be:

• Preventive: reduce the chance of an event, such as access restrictions.
• Detective: identify events, such as security monitoring.
• Corrective: restore or correct conditions, such as incident response.
• Deterrent: discourage harmful behaviour, such as sanctions and visible monitoring.
• Compensating: provide an alternative where a preferred control is impractical.

Controls may also be administrative, technical, physical or contractual. Effective programmes use defence in depth rather than relying on one control.

4.2 Design and operating effectiveness

A control has design effectiveness when it is capable of addressing the relevant risk. It has operating effectiveness when it functions as intended over the required period.

For example, a policy requiring quarterly access reviews may be well designed. If reviews are not performed, or evidence cannot be produced, the control is not operating effectively. Evidence may include approval records, system logs, tickets, training records, test results and management reports.

Control assessment should ask:

1. What risk does the control address?
2. Who owns and operates it?
3. What is its frequency and scope?
4. What evidence demonstrates performance?
5. What exceptions exist?
6. How is failure detected and corrected?

4.3 Control selection and prioritisation

Controls should be proportionate to risk and aligned with business requirements. Common control families include identity and access management, secure configuration, vulnerability management, encryption, backup and recovery, supplier security, incident response, security awareness, logging and physical protection.

A control catalogue is not a substitute for analysis. Organisations should avoid implementing controls merely because they appear in a standard. The relevant question is whether the control addresses a defined risk and whether its cost and operational effect are justified.

5. Risk Treatment

Risk treatment options are commonly described as follows:

Transfer does not remove accountability. An outsourced organisation may perform a service, but the data owner may retain legal, regulatory and governance responsibilities. Contracts should address security requirements, incident notification, audit rights, subcontracting, data location, retention and termination.

A risk treatment plan should include the risk statement, selected controls, responsible owner, target date, resources, dependencies, acceptance criteria and residual-risk decision. Treatment plans should be tracked like other business commitments.

6. Major Compliance and Security Frameworks

6.1 ISO/IEC 27001

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining and continually improving an Information Security Management System (ISMS). Its central idea is management-system governance: the organisation defines scope, leadership responsibilities, risk processes, objectives, documented information, operational controls, performance evaluation and improvement.

An ISMS is not merely a list of technical safeguards. It is a systematic management structure linking policy, risk assessment, treatment, competence, measurement, internal audit and corrective action. Organisations may seek certification against the requirements of the standard through an independent certification process.

A Statement of Applicability records which controls are applicable, their implementation status and the justification for inclusion or exclusion. The current ISO/IEC 27001 control structure should be consulted directly because standards are revised over time.

6.2 ISO/IEC 27002

ISO/IEC 27002 provides guidance and a reference set of information-security controls. It helps organisations interpret, design and implement controls, whereas ISO/IEC 27001 contains the auditable ISMS requirements. The two standards are complementary but not identical:

• ISO/IEC 27001: requirements for the management system and risk-based implementation.
• ISO/IEC 27002: guidance on information-security controls and implementation considerations.

A control should be selected because of the organisation’s risk and context, not because every possible control is automatically mandatory.

6.3 NIST Cybersecurity Framework

The NIST CSF provides a flexible structure for managing cybersecurity risk. Its well-known functions are:

• Govern: establish and monitor the organisation’s cybersecurity risk-management strategy.
• Identify: understand assets, risks, dependencies and opportunities for improvement.
• Protect: implement safeguards.
• Detect: discover and analyse possible attacks or compromises.
• Respond: contain, communicate and manage incidents.
• Recover: restore capabilities and improve resilience.

The CSF can be used to describe a current profile, define a target profile, analyse gaps and prioritise improvement. Unlike a certification standard, it is generally used as a flexible reference framework. Its value lies in communication and prioritisation across technical, operational and executive groups.

6.4 Other relevant frameworks

The following frameworks may complement ISO and NIST:

• CIS Critical Security Controls: prioritised safeguards with practical implementation guidance.
• COBIT: governance and management of enterprise information and technology.
• ISO 31000: general principles and guidance for risk management.
• ISO 22301: business continuity management systems.
• PCI DSS: requirements for environments handling payment-card data.
• Privacy frameworks and data-protection laws: obligations concerning personal data, lawful processing, rights, security and breach response.
• SOC 2 criteria: assurance reporting concerning controls relevant to security, availability, processing integrity, confidentiality and privacy.

These instruments have different purposes. A framework may guide governance, provide control guidance, establish legal obligations, or support independent assurance. They should not be presented as interchangeable.

7. Mapping Frameworks Without Creating Compliance Illusions

Organisations often create a crosswalk mapping one framework to another. Crosswalks reduce duplication and help identify common controls, but a mapping is not proof of compliance. Similar wording may hide differences in scope, evidence, implementation detail or legal interpretation.

A robust mapping process should:

1. define the scope and system boundary;
2. identify the authoritative requirement;
3. map the requirement to an accountable control;
4. identify evidence and control frequency;
5. record gaps and exceptions;
6. test design and operating effectiveness;
7. preserve ownership and review dates.

For example, an access-control procedure may support ISO/IEC 27001, ISO/IEC 27002 and the NIST CSF Protect function. However, each framework may require different documentation, assessment methods or evidence. One procedure can support multiple objectives, but it must still satisfy each applicable obligation.

8. Applied Case: Illustrative Regional Online Retailer

Background

BrightCart is a fictional regional online retailer. It processes customer identities, addresses and payment-related information through a cloud-hosted platform. It has 180 employees, a small security team and several logistics suppliers. The organisation wants to align its security programme with ISO/IEC 27001 and use the NIST CSF for operational communication.

Problem

A review finds that administrator accounts use passwords without MFA, critical cloud logs are retained for only seven days, supplier access is not reviewed consistently, and backups have never undergone a full restoration test. The organisation has written policies but limited evidence that controls operate consistently.

Analysis

The key assets are the customer database, order-processing service, administrator identities, payment integration, cloud tenancy and supplier connections. Important threats include credential theft, ransomware, supplier compromise and accidental deletion. The most significant vulnerabilities are weak privileged authentication, incomplete monitoring, excessive supplier access and untested recovery.

The risk team assesses privileged account takeover as likelihood 4 and impact 5, producing a qualitative score of 20. Ransomware affecting order processing is likelihood 3 and impact 5, producing a score of 15. These scores are prioritisation indicators, not probabilities.

Approach and solution

BrightCart creates an ISMS scope covering the e-commerce platform, supporting identity services, relevant employees and critical suppliers. It assigns asset owners and approves risk criteria. Treatment actions include:

• MFA for privileged and remote access;
• privileged-access management and quarterly access reviews;
• centralised logging with alerting and longer retention;
• supplier security clauses, due diligence and access expiry;
• immutable or segregated backups and documented restoration tests;
• an incident-response exercise involving technology, legal, communications and senior management.

The ISO/IEC 27001 risk-treatment plan records ownership, deadlines and residual-risk acceptance. ISO/IEC 27002 guidance helps describe control implementation. The NIST CSF is used to report progress: asset and supplier inventories support Identify; MFA and backups support Protect; monitoring supports Detect; exercises support Respond and Recover.

Outcome

After implementation, BrightCart has reduced exposure to account takeover and improved its ability to detect and recover from incidents. The organisation also discovers that supplier access remains a residual risk because one logistics provider cannot yet support modern authentication. Management documents the exception, limits the connection, increases monitoring and sets a remediation date.

Learning points

The case demonstrates that compliance is a management process rather than a paperwork exercise. It also shows why residual risk must remain visible, why supplier risk belongs within the assessment boundary, and why a control must be tested rather than merely documented.

9. Governance, Ethics and Regulatory Considerations

Cyber risk decisions affect individuals and communities. Excessive monitoring may intrude on privacy; automated risk scoring may unfairly classify users; aggressive testing may disrupt services; and disclosure decisions may affect victims, regulators and investigators. Security professionals should apply necessity, proportionality, transparency, least privilege and accountability.

Legal duties vary by jurisdiction and sector. Relevant obligations may include data-protection law, breach notification, records retention, critical-infrastructure regulation, payment security requirements, employment law and contractual commitments. A risk assessment should identify applicable obligations but should not treat a framework certificate as legal advice or as evidence that all legal duties have been met.

Boards and senior managers should receive risk information in business terms: affected services, plausible consequences, treatment options, resource needs, deadlines and residual exposure. Technical metrics such as vulnerability counts are useful only when connected to exploitability, asset criticality and remediation progress.

10. Contemporary Developments and Limitations

Cloud computing, software supply chains, remote work, operational technology and artificial intelligence have expanded the risk boundary. Organisations must assess shared-responsibility models, application programming interfaces, machine identities, third-party software, data flows and model-related risks such as sensitive-data leakage, prompt manipulation and unreliable outputs.

Artificial intelligence can assist with asset discovery, log analysis, vulnerability prioritisation and control evidence collection. It can also introduce errors, opacity, privacy concerns and automation bias. AI-generated assessments require human validation, documented data sources and appropriate access restrictions.

Risk assessment itself has limitations. Threat information is incomplete, impacts are difficult to estimate, dependencies may be hidden, and ordinal matrices can create artificial precision. Quantitative models may be distorted by poor data or changing threat conditions. Frameworks can also encourage checklist behaviour. The best practice is to combine structured frameworks with professional judgement, testing, scenario analysis, incident learning and continuous review.

Best-Practice Checklist

A mature cyber risk programme should:

• begin with business services and accountable owners;
• maintain accurate asset and dependency inventories;
• assess people, processes, technology, suppliers and physical environments;
• distinguish inherent risk from residual risk;
• use consistent criteria and record assumptions;
• link every treatment action to an identified risk;
• test both control design and operating effectiveness;
• retain evidence suitable for audit and management review;
• exercise incident response and recovery arrangements;
• review risks after major changes and significant incidents;
• communicate uncertainty rather than hiding it behind scores;
• treat compliance as a baseline for responsible governance, not as the complete definition of security.

Chapter Summary

Cyber risk management is the disciplined process of identifying assets, threats and vulnerabilities, analysing likelihood and impact, evaluating controls, selecting treatments and monitoring residual risk. Asset owners, risk criteria and business context are essential because the significance of a cyber event depends on organisational objectives and consequences.

Qualitative matrices support prioritisation, while quantitative models such as ALE = SLE × ARO may support economic analysis when reliable assumptions exist. Controls must be assessed for design and operating effectiveness. Risk may be avoided, reduced, shared or retained, but transfer does not eliminate accountability.

ISO/IEC 27001 provides requirements for an Information Security Management System; ISO/IEC 27002 provides control guidance; and the NIST CSF organises cybersecurity outcomes through Govern, Identify, Protect, Detect, Respond and Recover. Other frameworks address governance, continuity, payment security, privacy and assurance. Crosswalks can reduce duplication but cannot replace scope analysis, evidence and testing.

Effective compliance is therefore risk-based, evidence-based and continually improved. It requires technical safeguards, accountable governance, ethical judgement, legal awareness and clear communication of residual risk.

Key Terms

Asset: Something valuable that requires protection.

Asset owner: The person or function accountable for an asset and its protection requirements.

Threat: A potential cause of an unwanted incident.

Vulnerability: A weakness that may be exploited or triggered.

Risk: The effect of uncertainty on objectives.

Likelihood: An assessment of how probable or frequent an event may be.

Impact: The consequence of an event for an organisation or stakeholder.

Inherent risk: Risk before considering controls.

Residual risk: Risk remaining after controls and treatments.

Control: A measure that modifies risk.

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

Risk treatment: The process of selecting and implementing responses to risk.

ISMS: Information Security Management System.

Statement of Applicability: A record of applicable security controls, implementation status and justification.

ISO/IEC 27001: A standard specifying requirements for an ISMS.

ISO/IEC 27002: Guidance on information-security controls and implementation.

NIST CSF: A cybersecurity risk framework organised around functions and outcomes.

Control effectiveness: The degree to which a control is suitably designed and operates as intended.

Residual-risk acceptance: A documented decision to retain remaining risk.

Review Questions

Short Answer Questions

1. Distinguish a threat from a vulnerability.
2. What is the difference between inherent risk and residual risk?
3. State the three elements of the CIA triad.
4. What is the purpose of a Statement of Applicability?
5. Name the six functions of the NIST Cybersecurity Framework.

Long Answer Questions

1. Explain the stages of a cyber risk assessment from establishing context to monitoring residual risk.
2. Compare ISO/IEC 27001 and ISO/IEC 27002 in terms of purpose and use.
3. Explain how asset valuation should consider business processes, dependencies and recovery requirements.
4. Discuss the difference between control design effectiveness and operating effectiveness, using examples.
5. Explain why compliance with a framework does not automatically establish legal compliance or effective security.

Analytical / Application Questions

1. A public-facing identity service has a likelihood score of 4 and an impact score of 5. Using the qualitative convention R = L × I, calculate its score and explain two limitations of interpreting that number.
2. An organisation estimates a single incident loss of $60,000 and an annual rate of occurrence of 0.2. Calculate the annualised loss expectancy and discuss whether a control costing $10,000 per year should automatically be purchased.
3. Design a brief treatment plan for a supplier that has excessive access to confidential customer data and cannot yet implement MFA. Include immediate controls, residual risk and governance actions.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a vulnerability from a threat?

A. A vulnerability is a potential cause of harm, while a threat is a weakness.

B. A vulnerability is a weakness, while a threat is a potential cause of an unwanted incident.

C. A vulnerability is always an incident, while a threat is always a control.

D. A vulnerability measures impact, while a threat measures asset value.

Correct Answer: B. A vulnerability is a weakness, while a threat is a potential cause of an unwanted incident.

Question 2

An organisation assigns likelihood 3 and impact 5 to a risk. Using R = L × I, what is the risk score?

A. 8

B. 10

C. 15

D. 20

Correct Answer: C. 15

Question 3

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

A. ISO/IEC 27001

B. ISO/IEC 27002

C. ISO 22301

D. ISO 31000

Correct Answer: A. ISO/IEC 27001

Question 4

Which NIST CSF function includes discovering and analysing possible cybersecurity attacks or compromises?

A. Govern

B. Protect

C. Detect

D. Recover

Correct Answer: C. Detect

Question 5

What does residual risk mean?

A. Risk before any controls are considered

B. Risk remaining after controls and treatments are applied

C. Risk transferred entirely to an insurer

D. Risk that has no identified asset

Correct Answer: B. Risk remaining after controls and treatments are applied

Question 6

Which is an example of a detective control?

A. Security log monitoring and alerting

B. A firewall rule blocking unauthorised traffic

C. A backup restoration procedure

D. A policy requiring employee training

Correct Answer: A. Security log monitoring and alerting

Question 7

An incident has a single-loss expectancy of $80,000 and an annual rate of occurrence of 0.25. What is the annualised loss expectancy?

A. $20,000

B. $32,000

C. $80,250

D. $320,000

Correct Answer: A. $20,000

Question 8

Why does transferring cyber risk to a service provider not necessarily remove the customer organisation’s accountability?

A. Service providers cannot implement controls.

B. Contracts cannot address cybersecurity.

C. The customer may retain legal, regulatory and governance responsibilities.

D. Transferred risks are always higher than retained risks.

Correct Answer: C. The customer may retain legal, regulatory and governance responsibilities.

Question 9

Which statement best describes ISO/IEC 27002?

A. It provides guidance on information-security controls and implementation.

B. It is a law that replaces all data-protection requirements.

C. It is a method for calculating annualised loss expectancy.

D. It is a certification for payment-card environments only.

Correct Answer: A. It provides guidance on information-security controls and implementation.

Question 10

What is the main weakness of treating a risk-matrix score as a precise probability?

A. Risk matrices cannot compare any risks.

B. Ordinal scores are prioritisation conventions and may not represent equal numerical intervals.

C. Impact is never relevant to cybersecurity.

D. Likelihood cannot be assessed by organisations.

Correct Answer: B. Ordinal scores are prioritisation conventions and may not represent equal numerical intervals.