Cyber Security Basics

Chapter 3
Security Risk Management and Control Frameworks

Bachelors Program in IT
Cyber Security Basics   •   Bachelor

Security Risk Management and Control Frameworks

Introduction

Cybersecurity is not achieved by purchasing tools alone. It is a management discipline concerned with uncertainty: an organization must decide which adverse events could occur, how damaging they would be, how likely they are, and which safeguards provide proportionate protection. Security risk management connects business objectives with technical and administrative controls.

Risk management is particularly important because resources are limited. No organization can eliminate every vulnerability or guarantee that an incident will never occur. Instead, it must make defensible decisions about priorities, treatment options, residual exposure, and accountability. Frameworks such as the NIST Cybersecurity Framework (NIST CSF), ISO/IEC 27001, and the CIS Critical Security Controls provide structured ways to organize these decisions. They are complementary rather than interchangeable: one emphasizes a flexible cybersecurity lifecycle, another establishes an information security management system, and another provides prioritized technical and organizational safeguards.

This chapter explains how to identify, analyze, evaluate, prioritize, and treat cyber risk using qualitative and quantitative methods. It also examines how control categories support risk-based decisions and how governance, ethics, regulation, and emerging technologies influence implementation.

Learning Objectives

After studying this chapter, you should be able to:

  • explain the relationship among assets, threats, vulnerabilities, likelihood, impact, and risk;
  • distinguish qualitative, semi-quantitative, and quantitative risk analysis;
  • calculate and interpret single-loss expectancy and annualized loss expectancy under stated assumptions;
  • compare risk treatment options and explain residual risk;
  • interpret the structure and purpose of NIST CSF, ISO/IEC 27001, and CIS Controls;
  • map business risks to control categories and measurable outcomes;
  • evaluate limitations, ethical issues, and governance responsibilities in security risk management.

1. Foundations of Cybersecurity Risk

1.1 Risk, threat, vulnerability, and control

A risk is the effect of uncertainty on objectives. In cybersecurity, the effect may involve unauthorized disclosure, alteration, destruction, interruption, fraud, legal exposure, or loss of trust. A threat is a circumstance or actor capable of causing harm, such as ransomware, credential theft, insider misuse, equipment failure, or a natural disaster. A vulnerability is a weakness that can be exploited or otherwise contribute to an adverse event. A control is a measure that modifies risk.

Controls may be:

  • Preventive, such as multifactor authentication or secure configuration;
  • Detective, such as intrusion detection and audit logging;
  • Corrective, such as system restoration and malware removal;
  • Deterrent, such as disciplinary policies and visible monitoring;
  • Compensating, providing alternative protection when a preferred control is impractical.

A useful conceptual relationship is:

Risk = Likelihood × Impact

This is a decision model, not a universal physical law. It assumes that likelihood and impact have been represented on compatible scales and that the organization accepts a multiplicative approximation. In many practical assessments, exact probabilities are unavailable; therefore, ordinal ratings such as Low, Medium, and High are used. Such ratings support comparison but should not be interpreted as precise probabilities.

Risk exists in relation to an asset and an objective. For example, the same vulnerability may be low risk on an isolated test workstation but high risk on a payment database. Asset valuation should consider confidentiality, integrity, availability, legal obligations, safety, operational continuity, and reputation.

1.2 Inherent, current, and residual risk

Inherent risk is the exposure before considering controls. Current risk reflects controls already operating. Residual risk is the exposure remaining after a treatment has been implemented or accepted. A control does not necessarily eliminate risk; it changes likelihood, impact, or both.

A mature assessment distinguishes between:

  1. Design effectiveness: whether a control is appropriately designed;
  2. Operating effectiveness: whether it works consistently in practice;
  3. Coverage: whether it protects the relevant assets, users, systems, and locations;
  4. Evidence: whether performance can be demonstrated.

A policy stating that privileged accounts must use multifactor authentication is not equivalent to verified enforcement across all privileged accounts.

1.3 Risk appetite and tolerance

Risk appetite is the broad amount and type of risk an organization is willing to pursue or retain in achieving objectives. Risk tolerance is the acceptable variation around a specific objective or process. For example, a hospital may have very low tolerance for unauthorized alteration of medication records, while accepting moderate availability risk for a noncritical public-information website.

Risk decisions should be owned by accountable business leaders, not delegated entirely to technical staff. Security professionals provide analysis and recommendations; executives and process owners decide how much risk the organization will accept within legal and strategic constraints.

2. The Risk Management Process

A practical risk process is iterative rather than a one-time project.

Step 1: Establish context

Define the organization’s objectives, scope, systems, stakeholders, legal requirements, risk criteria, and assessment assumptions. Establish the time horizon and identify dependencies such as cloud providers, managed service providers, telecommunications, software suppliers, and critical personnel.

Step 2: Identify assets and business processes

Create an inventory of information, applications, devices, services, facilities, identities, and third parties. Link assets to business processes. An asset inventory that lists servers but not the processes they support is technically incomplete from a risk perspective.

Step 3: Identify threats and vulnerabilities

Use multiple sources: threat intelligence, vulnerability scans, penetration tests, incident records, audit findings, architecture reviews, vendor assessments, and staff reporting. Threat modeling should consider actors, capabilities, motivations, attack paths, and trust boundaries. Vulnerability severity alone does not determine business risk; exploitability and business context matter.

Step 4: Analyze likelihood and impact

Estimate how plausible an event is and what consequences would follow. Consider direct losses, recovery costs, downtime, regulatory penalties, litigation, safety effects, competitive harm, and long-term reputational damage. Document uncertainty rather than hiding it behind a single score.

Step 5: Evaluate and prioritize

Compare results with risk appetite, tolerance, legal duties, and available resources. Prioritize risks requiring treatment, monitoring, transfer, or formal acceptance. A high technical severity does not automatically outrank a moderate vulnerability affecting a critical process.

Step 6: Select and implement treatment

Choose controls and assign an owner, budget, deadline, implementation condition, and success measure. Treatment plans should address root causes rather than merely symptoms.

Step 7: Monitor and review

Reassess when systems, suppliers, threats, regulations, or business processes change. Track control performance, incidents, exceptions, and residual risk. Risk registers should be living management records, not documents created only for an audit.

3. Qualitative and Quantitative Risk Analysis

3.1 Qualitative analysis

Qualitative analysis uses categories and expert judgment. A common method assigns likelihood and impact values from 1 to 5, then uses a risk matrix. For example, likelihood may range from Rare to Almost Certain, while impact may range from Insignificant to Severe.

The method is useful when data are scarce, rapid decisions are needed, or consequences are difficult to monetize. It supports workshops and communication with nontechnical stakeholders. However, ratings may suffer from inconsistent interpretation, anchoring, optimism bias, and false precision. The organization should define each rating with evidence-based criteria.

For example, “High likelihood” might mean that exploitation is observed in the wild, the asset is internet-facing, and no effective control exists. “High impact” might mean prolonged interruption of a critical service, a reportable breach, or a significant safety consequence.

3.2 Semi-quantitative analysis

Semi-quantitative methods assign numerical scores to categories but do not claim that the scores are precise monetary probabilities. A weighted model can be used when dimensions such as confidentiality, integrity, availability, and regulatory exposure must be considered. The weights and scales must be documented, tested, and reviewed.

Scores should not be added or multiplied mechanically without understanding their meaning. A score of 80 is not necessarily twice as risky as a score of 40. Numerical ranking is valuable for prioritization, but it does not remove judgment.

3.3 Quantitative analysis

Quantitative analysis expresses likelihood and consequences using numerical estimates. A foundational model is the expected annual loss.

SLE = Asset Value × Exposure Factor

The single-loss expectancy (SLE) is the estimated loss from one occurrence. Asset Value is the value relevant to the loss scenario, measured in currency or another defined unit. The Exposure Factor is the proportion of value lost in one event, expressed between 0 and 1. This model assumes that the exposure factor is meaningful for the particular asset and event.

ALE = SLE × ARO

The annualized loss expectancy (ALE) is the expected loss per year. ARO, the annualized rate of occurrence, is the expected number of events per year. ARO may be less than 1; for example, an event expected once every five years has ARO = 0.2 per year. ALE is an expected value, not a guarantee: a result of $20,000 does not mean that exactly $20,000 will be lost each year.

#### Worked example

A university estimates that a ransomware event affecting a research file service would cause $400,000 of relevant loss if the service were effectively unusable. The estimated exposure factor is 0.35, and similar events are estimated to occur 0.4 times per year.

SLE = $400,000 × 0.35 = $140,000
ALE = $140,000 × 0.4 = $56,000 per year

The estimate suggests an expected annual loss of $56,000 under the stated assumptions. If a proposed control costs $30,000 per year and reduces the event frequency to 0.1 per year while leaving the impact unchanged, the post-control ALE is:

ALEafter = $140,000 × 0.1 = $14,000 per year

The estimated annual loss reduction is $42,000. A simple comparison suggests that the control may be economically justified because the estimated reduction exceeds its annual cost. However, the decision must also consider implementation costs, secondary benefits, uncertainty, legal duties, safety, and whether the control introduces new risks.

Quantitative analysis becomes more credible when estimates use incident history, actuarial data, threat intelligence, downtime records, and expert elicitation. Analysts should use ranges or scenarios when uncertainty is substantial. Expected values can conceal extreme but rare events; therefore, decision-makers should examine worst-case and high-percentile outcomes as well as averages.

4. Risk Treatment and Control Selection

Four standard treatment strategies are commonly recognized.

TreatmentMeaningExample
AvoidStop the activity creating unacceptable exposureDiscontinue an unsafe internet-facing service
MitigateReduce likelihood or impactPatch systems, segment networks, or improve recovery
Transfer/shareShift or share financial or operational consequencesCyber insurance or contractual allocation
Accept/retainKeep the risk within approved toleranceFormally accept low residual risk with an owner

Transfer does not make the underlying risk disappear. Insurance may reimburse some financial loss but cannot restore public trust, prevent harm to individuals, or remove regulatory responsibility. Acceptance must be explicit, informed, time-bound where appropriate, and approved by an authorized risk owner.

Control selection should follow a defense-in-depth principle. A strong design combines identity controls, secure configuration, vulnerability management, segmentation, data protection, monitoring, incident response, and recovery. Controls should be proportionate: excessive friction can lead users to bypass security, while weak controls may create unacceptable exposure.

Control objectives describe what must be achieved; controls describe how it will be achieved; metrics demonstrate whether it is working. For example, the objective may be “prevent unauthorized access to privileged systems.” Controls may include phishing-resistant authentication, privileged access management, least privilege, access reviews, and session logging. Metrics may include the percentage of privileged accounts using strong authentication and the time required to remove access after a role change.

5. Major Control Categories

Control categories provide a common language for organizing safeguards.

  • Governance and policy: accountability, policies, roles, risk criteria, and oversight.
  • Asset management: accurate inventories of hardware, software, data, services, and owners.
  • Identity and access management: authentication, authorization, least privilege, and lifecycle management.
  • Data security: classification, encryption, retention, backup, integrity, and secure disposal.
  • Secure configuration and vulnerability management: hardened baselines, patching, scanning, and remediation.
  • Network and application security: segmentation, secure development, testing, firewalls, and API protection.
  • Awareness and training: role-appropriate education and behavior reinforcement.
  • Monitoring and detection: logging, alerting, time synchronization, threat detection, and investigation.
  • Incident response: preparation, triage, containment, eradication, communication, and lessons learned.
  • Recovery and resilience: backups, continuity plans, recovery objectives, testing, and crisis management.
  • Third-party and supply-chain security: due diligence, contractual controls, assurance, and dependency monitoring.

No category is sufficient by itself. For example, endpoint detection cannot compensate for an unknown asset inventory, and encryption cannot compensate for stolen authentication credentials in every scenario.

6. Interpreting Major Frameworks

6.1 NIST Cybersecurity Framework

The NIST Cybersecurity Framework is a flexible, risk-based structure for managing cybersecurity. Its current conceptual organization uses the functions Govern, Identify, Protect, Detect, Respond, and Recover. Govern establishes strategy, policy, roles, oversight, and supply-chain expectations. Identify develops understanding of assets, risks, and improvement opportunities. Protect implements safeguards. Detect discovers cybersecurity events. Respond contains and manages incidents. Recover restores capabilities and communicates recovery activities.

The CSF is not a certification standard and does not prescribe one universal set of controls. Organizations can create a current profile describing outcomes presently achieved and a target profile describing desired outcomes. A gap analysis then identifies priorities. Tiers can help characterize the maturity and integration of cybersecurity risk management, but a higher tier is not automatically appropriate for every organization.

6.2 ISO/IEC 27001

ISO/IEC 27001 specifies requirements for an Information Security Management System (ISMS). An ISMS is a management system that establishes context, leadership, planning, support, operation, performance evaluation, and improvement. It requires organizations to determine information security risks, select appropriate treatments, maintain documented information, monitor performance, and improve the system.

The standard is associated with a risk-based Statement of Applicability, which records selected controls, their justification, and implementation status. ISO/IEC 27001 is auditable and can support certification by an accredited certification body. It does not mean that an organization is immune from attack, nor does certification guarantee that every technical control is perfect. Its strength is the integration of security into governance, repeatable processes, evidence, and continual improvement.

6.3 CIS Critical Security Controls

The CIS Controls provide a prioritized set of safeguards intended to reduce common and significant attack paths. They emphasize practical actions such as maintaining an asset inventory, managing software, protecting accounts, configuring systems securely, managing vulnerabilities, using audit logs, defending against malware, and maintaining data recovery capability. Implementation Groups help organizations select safeguards appropriate to their resources and risk profile.

The CIS Controls are operationally concrete and useful for building an initial improvement program. They do not replace enterprise risk governance, legal analysis, business continuity planning, or a complete ISMS.

6.4 Framework comparison

FrameworkPrimary emphasisTypical use
NIST CSFFlexible outcomes and risk communicationProfiles, gap analysis, program planning
ISO/IEC 27001Auditable information security management systemGovernance, certification, continual improvement
CIS ControlsPrioritized safeguards and implementation actionsPractical baseline and technical improvement

Frameworks can be combined. An organization may use ISO/IEC 27001 for governance and assurance, NIST CSF to communicate current and target outcomes, and CIS Controls to specify near-term technical actions. Mapping must be performed carefully because similar terms do not always have identical scope or evidence requirements.

7. Applied Case: Illustrative University Research Environment

Background

This illustrative case concerns Northbridge University, which operates a research data platform containing unpublished medical research, student records, and grant information. The platform is accessed by staff, students, external collaborators, and service providers. A review reveals incomplete asset records, inconsistent multifactor authentication, excessive privileges, and backups that have not been tested recently.

Problem

The university faces several connected risks: credential compromise could expose research data; ransomware could interrupt research; an external collaborator might retain access after a project ends; and unreliable backups could extend recovery time. The IT department initially proposes purchasing a new detection platform, but the risk review shows that basic identity and recovery weaknesses are more urgent.

Analysis

The assessment team defines the critical processes, identifies data owners, interviews researchers, reviews identity records, scans systems, and examines prior incidents. It rates risks using a documented likelihood-impact matrix and supplements the highest-priority scenarios with monetary estimates. The team distinguishes inherent risk from current risk and records uncertainty where evidence is weak.

The most important findings are:

  1. privileged accounts lack consistent phishing-resistant authentication;
  2. approximately 12% of active accounts have no confirmed current owner;
  3. critical servers have inconsistent patch timelines;
  4. backups exist but restoration has not been demonstrated;
  5. supplier access is not automatically removed when contracts end.

Approach and solution

Using NIST CSF, the university creates a target profile covering Govern, Identify, Protect, Detect, Respond, and Recover. ISO/IEC 27001 principles are used to assign risk owners, document treatment decisions, and establish review evidence. CIS Controls are used to sequence implementation.

The treatment plan includes:

  • completing an authoritative asset and account inventory;
  • enforcing strong authentication for privileged and remote access;
  • implementing joiner-mover-leaver processes;
  • establishing risk-based patch deadlines and exception approval;
  • separating backup administration from production administration;
  • testing restoration quarterly against defined recovery objectives;
  • restricting and monitoring supplier access;
  • centralizing logs for critical systems;
  • conducting incident-response exercises with research and legal stakeholders.

Outcome

After six months, all privileged accounts use strong authentication, unowned accounts have been removed or assigned, and restoration tests demonstrate that critical services can be recovered within the revised objective. The university has not eliminated risk, but it has reduced major attack paths, improved evidence, and made residual risks visible to accountable leaders. The detection-platform purchase is retained, but deployed after foundational controls rather than treated as a substitute for them.

Learning points

The case demonstrates that risk-based security begins with business processes and asset ownership. Frameworks help structure action, but they do not make decisions automatically. Basic controls, recovery capability, and accountability may produce greater risk reduction than a sophisticated tool deployed without reliable inventories or processes.

8. Governance, Ethics, Regulation, and Professional Practice

Risk management involves people whose privacy, livelihood, safety, or access to services may be affected. Monitoring should be lawful, necessary, proportionate, and transparent. Security teams should minimize collection of personal data, restrict access to monitoring records, define retention periods, and prevent security justifications from becoming unrestricted employee surveillance.

Organizations must also consider breach-notification duties, data-protection laws, sector regulation, contractual commitments, records-management requirements, and obligations to preserve evidence. Requirements vary by jurisdiction and industry; professionals should obtain appropriate legal advice rather than assuming that one framework satisfies every legal duty.

Ethically, risk assessments should not manipulate scores to obtain a preferred budget outcome. Analysts should disclose assumptions, conflicts of interest, data limitations, and scenarios omitted from analysis. Vendors should not claim that framework alignment equals guaranteed security. Executives should not accept risk informally while expecting technical staff to bear accountability for the result.

9. Contemporary Developments and Limitations

Cloud computing, software supply chains, remote work, operational technology, and artificial intelligence have expanded the attack surface and complicated ownership. Cloud customers and providers share responsibilities; a provider may secure the underlying infrastructure while the customer remains responsible for identities, configurations, data, and applications. Software bills of materials, signed updates, secure development practices, and supplier assurance can improve supply-chain visibility, although none is a complete solution.

Artificial intelligence can assist with alert triage, vulnerability prioritization, control mapping, and scenario analysis. It can also generate inaccurate conclusions, expose sensitive data, amplify bias, and create new attack paths through prompt manipulation or model compromise. AI-generated risk scores require human validation, traceable evidence, access controls, and appropriate testing.

Risk methods have important limitations. Qualitative ratings are subjective. Quantitative estimates can be undermined by sparse or biased data. Historical frequency may not predict novel attacks. ALE does not capture all strategic, ethical, or safety consequences. Framework checklists can encourage compliance theater if organizations measure documentation rather than actual resilience. Consequently, mature programs combine metrics with exercises, independent assurance, threat-informed analysis, and continuous learning.

Best Practices

  1. Begin with business objectives, critical services, and asset ownership.
  2. Define likelihood and impact scales before assigning ratings.
  3. Record assumptions, uncertainty, evidence, and risk owners.
  4. Prioritize exploitable weaknesses affecting important processes.
  5. Use layered controls rather than relying on a single technology.
  6. Test whether controls operate, not merely whether policies exist.
  7. Treat backup restoration and incident exercises as operational tests.
  8. Use frameworks as complementary tools, not as substitutes for judgment.
  9. Review third-party dependencies and shared-responsibility boundaries.
  10. Reassess after major technological, organizational, or threat changes.
  11. Make risk acceptance explicit, authorized, and reviewable.
  12. Protect privacy and maintain ethical transparency in monitoring and analysis.

Chapter Summary

Cybersecurity risk management is the disciplined process of understanding uncertainty and making proportionate decisions about protection. Risk analysis connects assets, threats, vulnerabilities, likelihood, and impact, while controls modify exposure through prevention, detection, response, and recovery. Qualitative methods support structured judgment; quantitative methods such as SLE and ALE provide economic estimates when assumptions and data justify them.

Risk may be avoided, mitigated, transferred, or accepted, but acceptance should be explicit and owned by accountable leaders. Control categories include governance, asset management, identity, data protection, secure configuration, monitoring, incident response, recovery, and supply-chain security. NIST CSF organizes outcomes through Govern, Identify, Protect, Detect, Respond, and Recover. ISO/IEC 27001 establishes an auditable, risk-based ISMS, while CIS Controls provide prioritized practical safeguards. Used together, these frameworks support governance, prioritization, implementation, and continual improvement.

Effective practice requires more than compliance documentation. It requires accurate inventories, tested controls, measurable outcomes, resilience, ethical handling of personal information, and continual reassessment. Technology, including AI, can assist risk management but cannot replace accountable human judgment.

Key Terms

Risk: The effect of uncertainty on objectives.

Threat: A circumstance or actor capable of causing harm.

Vulnerability: A weakness that can be exploited or contribute to harm.

Control: A measure that modifies risk.

Asset: Something valuable to an organization or process.

Inherent risk: Risk before considering controls.

Residual risk: Risk remaining after treatment.

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

Risk tolerance: Acceptable variation around a particular objective or activity.

Likelihood: An estimate of how plausibly an event may occur.

Impact: The consequence of an adverse event.

SLE: Single-loss expectancy from one occurrence.

ARO: Annualized rate of occurrence.

ALE: Annualized expected loss, calculated as SLE × ARO under stated assumptions.

Risk treatment: The process of selecting and applying measures to modify risk.

NIST CSF: A flexible framework for organizing cybersecurity outcomes and risk management.

ISO/IEC 27001: A standard specifying requirements for an information security management system.

CIS Controls: A prioritized set of cybersecurity safeguards.

Residual risk owner: The person accountable for a remaining risk and its treatment decision.

Defense in depth: The use of multiple complementary layers of protection.

Review Questions

Short Answer Questions

  1. Distinguish between a threat, a vulnerability, and a control.
  2. What is the difference between inherent risk and residual risk?
  3. Define risk appetite and risk tolerance.
  4. State the six functions of the NIST Cybersecurity Framework.
  5. Why does cyber insurance not eliminate cybersecurity risk?

Long Answer Questions

  1. Explain the stages of a complete cybersecurity risk management process, from establishing context through monitoring and review.
  2. Compare qualitative, semi-quantitative, and quantitative risk analysis, including the strengths and limitations of each.
  3. Explain how ISO/IEC 27001, NIST CSF, and CIS Controls can be used together in one security program.
  4. Discuss how an organization should select controls for a critical business process.
  5. Analyze the governance and ethical responsibilities associated with employee monitoring and security risk acceptance.

Analytical / Application Questions

  1. An organization estimates an asset value of $250,000, an exposure factor of 0.4, and an annualized rate of occurrence of 0.2. Calculate SLE and ALE, state the units, and explain what the ALE does and does not mean.
  2. A company has excellent endpoint detection but no verified asset inventory, inconsistent privileged authentication, and untested backups. Prioritize three actions and justify the order using risk-management principles.
  3. Design a one-year improvement plan for a small healthcare provider using NIST CSF, ISO/IEC 27001 principles, and CIS Controls. Identify owners, evidence of success, and at least two residual risks that may remain.

Multiple Choice Questions with Answers

Question 1

Which statement best describes residual risk?

A. Risk before any controls are considered

B. Risk remaining after controls or treatment are applied

C. Risk transferred entirely to an insurance company

D. Risk that has no identifiable threat

Correct Answer: B. Risk remaining after controls or treatment are applied

Question 2

An asset has a value of $100,000 and an exposure factor of 0.25. What is the single-loss expectancy?

A. $250

B. $2,500

C. $25,000

D. $400,000

Correct Answer: C. $25,000

Question 3

Which NIST CSF function establishes strategy, policy, roles, and oversight?

A. Protect

B. Detect

C. Govern

D. Recover

Correct Answer: C. Govern

Question 4

What is the primary emphasis of ISO/IEC 27001?

A. A prioritized list of endpoint signatures

B. An auditable information security management system

C. A guarantee that no cyberattack will succeed

D. A replacement for all legal requirements

Correct Answer: B. An auditable information security management system

Question 5

Which treatment strategy stops the activity that creates unacceptable exposure?

A. Avoid

B. Transfer

C. Accept

D. Monitor

Correct Answer: A. Avoid

Question 6

An event has an SLE of $50,000 and an ARO of 0.2. What is its ALE?

A. $10,000 per year

B. $50,000 per year

C. $100,000 per year

D. $250,000 per year

Correct Answer: A. $10,000 per year

Question 7

Which is the best example of a detective control?

A. Multifactor authentication

B. Centralized security logging and alerting

C. Data destruction

D. A disciplinary policy alone

Correct Answer: B. Centralized security logging and alerting

Question 8

Why should risk acceptance be formally documented?

A. To prove that the risk has been eliminated

B. To assign accountability and demonstrate an informed decision

C. To transfer all responsibility to technical staff

D. To avoid monitoring the risk in the future

Correct Answer: B. To assign accountability and demonstrate an informed decision

Question 9

What is a principal limitation of qualitative risk scores?

A. They can never support prioritization

B. They always require monetary loss data

C. They may create subjective or falsely precise comparisons

D. They cannot be explained to nontechnical stakeholders

Correct Answer: C. They may create subjective or falsely precise comparisons

Question 10

Which framework is especially useful for prioritized, practical cybersecurity safeguards?

A. CIS Critical Security Controls

B. NIST CSF Govern function only

C. An organization’s marketing plan

D. A disaster narrative without controls

Correct Answer: A. CIS Critical Security Controls

Cyber Security Basics
Chapter 3 of 15