Risk Treatment and Security Control Design

Introduction

Risk assessment does not reduce risk by itself. It produces knowledge about uncertainty, threats, vulnerabilities, consequences, and exposure. Risk treatment is the managerial and technical process through which an organisation decides what to do with that exposure and implements measures consistent with business objectives, legal duties, and stakeholder expectations.

In cybersecurity, treatment decisions are rarely purely technical. A control may improve confidentiality but reduce usability; a monitoring requirement may strengthen detection but create privacy concerns; outsourcing may transfer financial responsibility without transferring accountability. Consequently, effective treatment combines risk analysis, architecture, governance, financial judgment, auditability, and organisational change.

This chapter examines four principal treatment strategies—avoidance, mitigation, transfer, and acceptance—and explains how to select preventive, detective, corrective, and compensating controls. It then develops control objectives, evaluates control design, constructs risk treatment plans, and establishes meaningful security metrics.

Learning Objectives

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

1. Distinguish risk avoidance, mitigation, transfer, and acceptance.
2. Select controls according to risk, process, threat, and control purpose.
3. Formulate clear and testable security control objectives.
4. Assess whether controls are suitably designed, implemented, and operating.
5. Develop a defensible risk treatment plan with ownership, resources, and deadlines.
6. Design security metrics that measure control performance and risk outcomes.
7. Critically evaluate governance, ethical, regulatory, and practical limitations of treatment decisions.

1. From Risk Assessment to Risk Treatment

Risk can be understood as the effect of uncertainty on objectives. In information security, the relevant objectives commonly include confidentiality, integrity, availability, authenticity, privacy, safety, and regulatory compliance. A risk statement should connect a cause, an event, and a consequence. For example:

Because privileged accounts are not consistently protected by phishing-resistant authentication, an attacker may obtain administrative access, resulting in unauthorised changes to customer records and service disruption.

This form is more useful than a vague statement such as “access control risk,” because it identifies the condition that treatment must address.

A simple expected-loss model is sometimes useful for prioritisation:

Here, SLE is single-loss expectancy, measured in currency per incident; ARO is annual rate of occurrence, measured in incidents per year; and ALE is annualised loss expectancy, measured in currency per year. If an incident is expected to cost £200,000 and has an estimated annual frequency of 0.25, then ALE = £200,000 × 0.25 = £50,000 per year.

This model assumes that loss estimates and frequencies are sufficiently reliable and that losses are reasonably represented by an expected value. It does not capture uncertainty, catastrophic tail events, interdependencies, reputational harm, legal exposure, or the value of information. Therefore, ALE should inform judgment rather than mechanically determine treatment.

After controls are introduced, the remaining exposure is residual risk. In a simplified model:

The expression is conceptual, not a universally valid arithmetic law. Risk scores are often ordinal rather than ratio-scale values, so subtracting them may not be statistically meaningful. Organisations should define their scoring method, assumptions, and risk appetite explicitly.

2. Risk Treatment Strategies

2.1 Risk avoidance

Avoidance changes the activity, system, process, or objective so that the relevant risk no longer arises. Examples include discontinuing an unsafe service, refusing to store highly sensitive data, removing an exposed internet-facing interface, or choosing not to enter a market with unacceptable regulatory risk.

Avoidance is powerful when the activity is non-essential, the exposure is extreme, or effective controls are infeasible. It is not, however, cost-free. Avoiding online payment processing may eliminate payment-card risk but may also eliminate revenue. Avoidance can also relocate risk: abandoning an internal service and relying on an external platform may introduce supplier and concentration risk.

A sound avoidance decision should document:

• the objective being sacrificed or redesigned;
• the risk that is removed and risks introduced elsewhere;
• legal, contractual, and stakeholder consequences; and
• the decision authority and review date.

2.2 Risk mitigation or reduction

Mitigation reduces the likelihood, impact, or duration of a risk through controls. It is the most common strategy in information security. Examples include multifactor authentication, secure configuration, network segmentation, encryption, backups, vulnerability management, incident response, and security awareness.

Mitigation can be preventive, detective, corrective, or a combination. A web application firewall may prevent some attacks, detect suspicious requests, and support blocking actions. Controls should therefore be analysed by their actual function rather than by product category.

Mitigation is appropriate when the activity is necessary and risk can be reduced to a tolerable level. It does not imply that risk is eliminated. A control can fail, be bypassed, become obsolete, or create new operational risks.

2.3 Risk transfer or sharing

Transfer allocates some financial, operational, or contractual consequences to another party. Common mechanisms include insurance, outsourcing, cloud services, indemnity clauses, warranties, and managed security services.

Transfer rarely transfers accountability. A bank may outsource payment processing, but it remains responsible for selecting and overseeing the provider, protecting customers, and meeting applicable obligations. Insurance may reimburse defined losses but cannot restore trust, recover stolen data, or remove regulatory duties. Contracts should therefore specify security requirements, audit rights, breach notification, subcontracting, data location, service levels, recovery obligations, and exit arrangements.

Transfer can also create third-party, supply-chain, concentration, and lock-in risks. The treatment decision must assess both the original risk and the risk introduced by dependence on the counterparty.

2.4 Risk acceptance

Acceptance is a deliberate decision to retain risk within approved tolerance. It is not the same as neglect. Valid acceptance requires a documented rationale, identified residual risk, accountable approver, duration, monitoring arrangements, and trigger conditions for reconsideration.

Acceptance may be appropriate where treatment cost is disproportionate, the likelihood is low, the risk is already within appetite, or no feasible control exists. Acceptance is not appropriate merely because a team has missed a deadline or lacks budget. In such cases, management should distinguish temporary exception from permanent acceptance.

Comparative view

In practice, strategies are combined. An organisation may avoid storing full card numbers, mitigate remaining application risk, transfer some loss through insurance, and accept a low-level residual risk.

3. Security Controls and Their Purposes

A security control is a measure that modifies risk. Controls may be administrative, technical, physical, or a combination. A policy is not necessarily an effective control: it becomes a control only when it is implemented, communicated, followed, and capable of producing the intended result.

3.1 Preventive controls

Preventive controls act before an undesirable event or condition occurs. Examples include:

• least-privilege access and segregation of duties;
• secure software development requirements;
• multifactor authentication;
• input validation and output encoding;
• network segmentation and deny-by-default rules;
• encryption and key-management safeguards;
• physical barriers and environmental controls.

Preventive controls are valuable but cannot be assumed to block every attack. Authentication may prevent account takeover but not abuse by an authorised insider. Segmentation may limit movement but not eliminate compromise.

3.2 Detective controls

Detective controls identify events, deviations, or attempted violations. Examples include security information and event management, endpoint detection, access reviews, vulnerability scanning, fraud analytics, audit logs, and physical surveillance.

A detective control has little value if alerts are not reviewed or if logging is incomplete. Design should specify event sources, collection integrity, retention, analysis frequency, alert thresholds, escalation, and evidence preservation. Detection speed matters because an unnoticed compromise may expand substantially.

3.3 Corrective controls

Corrective controls restore an acceptable state after an incident or failure. Examples include malware removal, account revocation, patching, system restoration, disaster recovery, data correction, and lessons-learned actions.

Corrective capability depends on preparation. Backups that cannot be restored, incident procedures that have never been exercised, or emergency accounts without governance are weak controls despite appearing adequate on paper.

3.4 Compensating controls

A compensating control provides a reasonable alternative when the preferred control cannot be implemented. For example, where a legacy application cannot support multifactor authentication, an organisation might use a dedicated privileged-access workstation, network isolation, strong monitoring, and tightly controlled jump-host access.

A compensating control should address the same risk objective, not merely appear security-related. It should be documented with the reason for substitution, scope, limitations, owner, evidence, and expiry or review date. Compensating controls often increase operational complexity and should not become a permanent excuse for unmanaged technical debt.

4. Control Objectives: Designing the Intended Result

A control objective states what must be achieved, not merely what activity must be performed. Strong objectives are specific, risk-linked, testable, and aligned with business and compliance requirements.

Weak objective: “User access will be secure.”

Stronger objective: “Access to production customer data is granted only to authorised individuals for approved business purposes, reviewed at defined intervals, and removed promptly when the business need ends.”

A control objective should answer four questions:

1. What asset, process, or obligation is protected?
2. What condition must be achieved or prevented?
3. Who or what is responsible?
4. What evidence demonstrates achievement?

Objectives can be organised according to the information-security property involved:

Control objectives should be derived from risk statements, process requirements, contractual commitments, laws, and recognised control frameworks. Framework mappings are useful, but copying framework language without understanding the local risk produces compliance theatre.

5. Assessing Control Design

Control design assessment asks whether a control, if implemented and operated as described, is capable of addressing the risk. It is distinct from operating-effectiveness testing, which asks whether the control actually operated consistently during a defined period.

A control may be:

• Designed effectively: logically addresses the relevant risk and contains appropriate scope, authority, frequency, precision, and evidence.
• Designed ineffectively: cannot achieve the objective even if performed exactly as documented.
• Implemented but not operating effectively: suitable in concept but inconsistently performed, bypassed, or unsupported by evidence.

Design assessment dimensions

Risk linkage. Does the control address the stated threat, vulnerability, consequence, or obligation? A quarterly access review may not address real-time privilege abuse.

Coverage. Does it include all relevant systems, identities, locations, data types, suppliers, and failure modes? Sampling or exclusions must be justified.

Authority and accountability. Is an accountable owner designated? Are duties separated where self-review or fraud is possible?

Frequency and timeliness. Is the control performed often enough to manage the rate of change? A monthly review may be unsuitable where privileged access changes daily.

Precision. Can the control distinguish acceptable from unacceptable conditions? A vague “manager reviews access” control is weaker than one specifying evidence, criteria, exceptions, and resolution.

Reliability and independence. Can the control be bypassed by the person it is intended to constrain? Are logs protected from alteration? Is review independent enough to identify misconduct?

Evidence. Does the design generate complete, accurate, retrievable evidence? Evidence should identify scope, performer, date, result, exceptions, and resolution.

Resilience. Does the control continue during outages, emergencies, degraded operation, and changes to technology?

A useful assessment sequence is: identify the risk; state the objective; map the control mechanism; inspect scope and frequency; analyse failure modes; identify evidence; and conclude whether the design reduces the risk to the required level.

6. Developing a Risk Treatment Plan

A risk treatment plan converts decisions into accountable action. It should be integrated with enterprise planning, architecture, procurement, change management, and audit follow-up rather than maintained as an isolated spreadsheet.

A practical plan includes:

Treatment selection should consider effectiveness, cost, feasibility, time, user impact, resilience, and secondary risk. The cheapest control is not necessarily the most economical if it creates outages or excessive false positives. Conversely, a technically sophisticated control may be inappropriate if it cannot be maintained.

Where benefits and costs can be estimated, a simplified net-benefit comparison is:

Expected loss avoided is the difference between expected loss before and after treatment, subject to the same assumptions and time period. This is an analytical aid, not a substitute for legal, ethical, safety, or risk-appetite requirements. Some controls are mandatory even when their direct financial return is negative.

Treatment plans should distinguish implementation from assurance. “Deploy endpoint detection” is an implementation task; “demonstrate that all in-scope endpoints generate monitored telemetry and that alerts are triaged within the defined service level” is an assurance criterion.

7. Security Metrics and Measurement

Metrics support governance only when they answer a decision question. A count of blocked attacks may increase because attacks increased, detection improved, or reporting changed; it is not automatically evidence of better security.

7.1 Leading, operational, and outcome measures

• Leading indicators measure conditions expected to influence future risk, such as the percentage of critical systems with secure configuration baselines.
• Operational indicators measure control activity, such as the percentage of access reviews completed by their due date.
• Outcome indicators measure results, such as unauthorised access incidents or recovery performance.

A metric should have a defined population, numerator, denominator, time period, data source, owner, target, tolerance, and interpretation. For example:

The numerator and denominator must refer to the same reporting period and scope. If there are 96 timely reviews among 100 due reviews, the rate is 96%. The metric does not show whether reviews were performed carefully; it should be paired with exception quality and remediation measures.

Other useful measures include:

• mean time to detect and mean time to contain incidents;
• percentage of critical vulnerabilities remediated within the approved period;
• percentage of privileged accounts protected by phishing-resistant authentication;
• backup restoration success rate;
• percentage of suppliers with current security assessments;
• number and age of open high-risk exceptions;
• false-positive rate for key detection rules;
• recovery time achieved compared with the approved recovery time objective.

Mean time measures require a clear start and end definition. If detection times for incidents are 2, 5, and 8 hours, the arithmetic mean is (2 + 5 + 8) ÷ 3 = 5 hours. Means can conceal severe outliers, so median, percentile, and maximum values may also be appropriate.

Metrics can be gamed. Teams may close tickets prematurely, redefine scope, or avoid reporting. Governance should therefore encourage accurate reporting, periodically validate data, and combine quantitative metrics with independent assurance and qualitative analysis.

8. Applied Case: Northbridge Health Services

The following is an illustrative case, not a report of a real organisation.

Background

Northbridge Health Services operates outpatient clinics and a cloud-hosted patient portal. Clinicians require rapid access to records, while the organisation must protect health information and maintain service availability. An assessment identified excessive privileges, inconsistent multifactor authentication, incomplete supplier evidence, and unreliable restoration testing.

Problem

A compromised receptionist account had accessed more records than necessary. Investigation found that several shared workstations used password-only authentication, leavers’ access was not always removed promptly, and backup jobs reported success without regular restoration tests. Management initially proposed purchasing a larger monitoring platform.

Analysis

The principal risk was not simply “insufficient monitoring.” The risk statement was that weak identity lifecycle management and excessive privileges could enable unauthorised disclosure or alteration of patient information, with legal, clinical, and reputational consequences. Monitoring could detect some activity but would not correct excessive access or prevent password theft.

The team evaluated treatment options:

• Avoidance: discontinue the portal, which would reduce exposure but undermine patient access and service objectives.
• Mitigation: implement role-based access, phishing-resistant authentication for privileged and remote access, automated joiner-mover-leaver workflows, and tested backups.
• Transfer: require the cloud provider to meet contractual security and recovery obligations, while retaining Northbridge accountability.
• Acceptance: temporarily accept limited legacy-device exposure under a documented exception with network isolation and enhanced monitoring.

Approach and solution

Northbridge established these control objectives:

1. Patient records are accessible only according to current job responsibilities and approved care purposes.
2. Privileged and remote access is strongly authenticated and attributable to an individual.
3. Access is removed or changed promptly after employment or role changes.
4. Critical data can be restored within approved recovery requirements.

The treatment plan assigned the clinical operations director as risk owner, the identity manager as control owner, and the security team as assurance provider. It introduced monthly exception reporting, quarterly access certification for high-risk roles, automated deprovisioning, immutable backup copies, and semiannual restoration exercises. The supplier contract added breach notification, audit evidence, recovery testing, and subcontractor provisions.

Success measures included 100% of privileged accounts using approved strong authentication, 98% of leaver accounts disabled within four hours, restoration tests meeting the recovery objective, and no unresolved high-risk access exceptions beyond their approved expiry.

Outcome

After implementation, the organisation reduced unnecessary privileges and improved evidence quality. Restoration testing revealed that one application dependency had been omitted from the original recovery design; the plan was corrected before a real outage. The case demonstrates why control design must address prevention, detection, correction, ownership, and evidence together.

Learning points

First, a security product is not a treatment strategy by itself. Second, transfer does not remove accountability. Third, acceptance must be explicit and temporary where uncertainty is high. Finally, outcome measures and exercises expose weaknesses that policy compliance alone may miss.

9. Governance, Ethics, and Regulation

Treatment decisions must respect proportionality, fairness, privacy, and accountability. Excessive surveillance may improve detection while unjustifiably monitoring employees or patients. Biometric authentication can reduce account sharing but creates sensitive data-management obligations. Automated risk scoring may reproduce bias if data, thresholds, or assumptions disadvantage particular groups.

Governance should define who may accept which level of residual risk, when escalation is mandatory, and how conflicts are handled. Legal and regulatory requirements may establish minimum controls, breach reporting duties, retention limits, data-subject rights, sector obligations, or requirements for resilience. Compliance does not prove that a control is effective, and a control that is technically effective may still be unlawful or unethical if deployed without necessity, transparency, or due process.

Boards and senior management should receive risk information in business terms: critical services exposed, plausible consequences, treatment progress, exceptions, dependencies, and decisions required. Technical detail remains important for specialists, but governance fails when reports contain only tool outputs and no accountable decisions.

10. Contemporary Developments and Limitations

Cloud-native architectures, software supply chains, application programming interfaces, remote work, operational technology, and artificial intelligence complicate control design. Identity has become a central security boundary; machine identities, APIs, service accounts, and ephemeral workloads require lifecycle governance comparable to human accounts.

AI-assisted detection can process large volumes of telemetry and identify unusual patterns, but it introduces model drift, false positives, explainability, data-quality, and adversarial-manipulation concerns. AI-generated code and content also require secure development, provenance, privacy, and human review. Organisations should treat AI as a component within a controlled process, not as an autonomous substitute for accountability.

No treatment model predicts risk perfectly. Threats evolve, dependencies interact, estimates are uncertain, and controls can fail simultaneously. Mature organisations therefore use defence in depth, independent assurance, scenario exercises, threat-informed testing, and continuous improvement. They also revisit risk appetite when strategy, technology, regulation, or societal expectations change.

Best-Practice Principles

1. Write risk statements that connect causes, events, and consequences.
2. Select treatment based on risk appetite and business purpose, not technology fashion.
3. Design controls around explicit, testable objectives.
4. Combine preventive, detective, corrective, and compensating measures where appropriate.
5. Separate control ownership, risk ownership, and independent assurance.
6. Treat supplier contracts as part of the control environment, not as proof of security.
7. Make acceptance documented, authorised, time-bound, and monitored.
8. Test restoration, response, and failure modes rather than relying on documentation.
9. Use metrics that support decisions and validate their data quality.
10. Reassess controls when systems, threats, laws, suppliers, or business objectives change.

Chapter Summary

Risk treatment converts risk knowledge into decisions and action. Avoidance stops or redesigns an activity; mitigation reduces likelihood or impact; transfer shares defined consequences without removing accountability; and acceptance retains risk through an explicit authorised decision. These approaches are often combined.

Controls should be selected according to their purpose. Preventive controls act before an event, detective controls identify events or deviations, corrective controls restore an acceptable state, and compensating controls provide a justified alternative when the preferred control is infeasible. A control objective describes the intended result and should be linked to a risk, owner, scope, frequency, evidence, and decision criterion.

Control design assessment asks whether a control is capable of achieving its objective; operating-effectiveness assessment asks whether it actually operated consistently. Risk treatment plans should record ownership, resources, dependencies, milestones, evidence, residual-risk approval, and review triggers. Metrics must have clear populations, definitions, data sources, targets, and interpretations. Financial models such as ALE can support prioritisation but cannot replace professional judgment, legal duties, ethical analysis, or resilience testing.

Key Terms

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

Risk avoidance: Changing or stopping an activity so that a risk no longer arises.

Risk mitigation: Reducing the likelihood, impact, or duration of risk.

Risk transfer: Sharing defined risk consequences with another party.

Risk acceptance: Authorised retention of risk within approved tolerance.

Residual risk: Risk remaining after treatment measures are applied.

Inherent risk: Risk assessed before considering controls.

Security control: A measure that modifies information-security risk.

Preventive control: A control intended to stop an undesirable event or condition.

Detective control: A control intended to identify an event, deviation, or violation.

Corrective control: A control intended to restore an acceptable state after failure.

Compensating control: An alternative control used when the preferred control is infeasible.

Control objective: The result or condition a control is intended to achieve.

Control design: The structure and logic by which a control is expected to address risk.

Operating effectiveness: The extent to which a control operates consistently and as designed.

Risk treatment plan: An accountable schedule of actions for managing identified risks.

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

Security metric: A defined measurement used to evaluate security conditions, activities, or outcomes.

Single-loss expectancy: Estimated loss from one occurrence of an incident.

Annualised loss expectancy: Expected loss over a year, calculated from loss per event and annual frequency.

Review Questions

Short Answer Questions

1. What is the difference between risk mitigation and risk avoidance?
2. Why does risk transfer not normally remove organisational accountability?
3. Distinguish preventive, detective, and corrective controls.
4. What characteristics make a control objective testable?
5. Why should security metrics include a defined denominator and reporting period?

Long Answer Questions

1. Compare avoidance, mitigation, transfer, and acceptance, including circumstances in which each may be appropriate.
2. Explain how an auditor would assess the design of an access-control review.
3. Discuss the relationship between control objectives, risk treatment plans, and assurance evidence.
4. Explain the limitations of annualised loss expectancy as a basis for cybersecurity investment.
5. Discuss ethical and governance issues associated with surveillance and AI-assisted security monitoring.

Analytical / Application Questions

1. A university cannot upgrade a legacy research system to support multifactor authentication. Develop a treatment decision using compensating controls, and specify the control objective, owner, evidence, expiry date, and residual-risk approval.
2. An organisation reports a 99% patch-completion rate but continues to suffer exploitable vulnerabilities. Diagnose at least four weaknesses in the metric or control design and propose improved measures.
3. A cloud supplier offers contractual indemnity but refuses independent audit rights and provides limited restoration evidence. Analyse whether transfer is an adequate treatment and recommend a combined treatment plan.

Multiple Choice Questions with Answers

Question 1

Which treatment strategy changes or stops an activity so that the associated risk no longer arises?

A. Risk acceptance

B. Risk avoidance

C. Risk transfer

D. Risk monitoring

Correct Answer: B. Risk avoidance

Question 2

Which control purpose is primarily concerned with identifying suspicious events or deviations?

A. Preventive

B. Detective

C. Corrective

D. Compensating

Correct Answer: B. Detective

Question 3

A compensating control is most appropriate when:

A. The preferred control is infeasible and an alternative addresses the same objective

B. Management wants to avoid documenting residual risk

C. A control has no relationship to the identified risk

D. An organisation wants to eliminate all monitoring

Correct Answer: A. The preferred control is infeasible and an alternative addresses the same objective

Question 4

An incident has an estimated single-loss expectancy of £200,000 and an annual rate of occurrence of 0.25. What is the annualised loss expectancy?

A. £50,000 per year

B. £200,000 per year

C. £800,000 per year

D. £250,000 per year

Correct Answer: A. £50,000 per year

Question 5

Which statement best distinguishes control design assessment from operating-effectiveness testing?

A. Design assessment evaluates capability; operating testing evaluates actual consistent performance

B. Design assessment is financial; operating testing is technical

C. Design assessment occurs only after an incident

D. Operating testing does not require evidence

Correct Answer: A. Design assessment evaluates capability; operating testing evaluates actual consistent performance

Question 6

Which item is essential to a valid risk-acceptance decision?

A. An undocumented verbal agreement

B. An accountable approver and defined review or expiry conditions

C. A promise that the risk will never occur

D. A requirement to purchase cyber insurance

Correct Answer: B. An accountable approver and defined review or expiry conditions

Question 7

A metric records 96 access reviews completed by their due dates out of 100 reviews due. What is the completion rate?

A. 4%

B. 96%

C. 100%

D. 104%

Correct Answer: B. 96%

Question 8

Which is the strongest control objective?

A. Users will be secure

B. Access will be managed appropriately

C. Production customer-data access will be authorised, periodically reviewed, and removed when no longer required

D. The organisation will buy an access-management tool

Correct Answer: C. Production customer-data access will be authorised, periodically reviewed, and removed when no longer required

Question 9

Why is outsourcing security processing not sufficient to eliminate the organisation’s risk?

A. Suppliers cannot operate technical controls

B. Outsourcing always increases likelihood to zero

C. Accountability and oversight obligations generally remain with the organisation

D. Contracts have no relevance to security

Correct Answer: C. Accountability and oversight obligations generally remain with the organisation

Question 10

Which measure is most directly an outcome indicator?

A. Percentage of staff completing training

B. Number of security policies published

C. Percentage of critical vulnerabilities remediated within the required period

D. Number of security meetings held

Correct Answer: C. Percentage of critical vulnerabilities remediated within the required period