CISM Information Security Risk Response: Treatment Options, Ownership and Monitoring

Information security risk response is the stage of the risk management life cycle in which the organization decides what to do about each assessed risk, assigns who is accountable for it, and then monitors and reports whether the risk stays within what senior management will accept. Assessment tells you how big a risk is; response decides whether to reduce it, share it, stop the activity that creates it or live with it, and then proves that the decision is working.

The CISM 2026 outline groups this work under three headings, and this lesson follows them:

• Risk treatment / risk response options: mitigate, transfer, avoid or accept, chosen against risk appetite and cost, including compensating controls and the security exception process.
• Risk and control ownership: who decides on a risk, who operates each control, and what the information security manager does in between.
• Risk monitoring and reporting: treatment plans, the risk register, key risk indicators (KRIs), effectiveness testing and escalation to senior management.

The manager's role is to recommend and facilitate, not to decide on the business's behalf. The information security manager identifies treatment options, works out their cost and effect, presents them in business terms and keeps the record accurate. The risk owner, a business manager with authority over the activity, makes the decision, and senior management (which set the appetite) decides anything beyond the owner's authority. Identifying threats, analysing likelihood and impact, and reassessing risk when things change belong to the companion lesson on information security risk assessment.

Every risk response is one of four options, or a combination of them: mitigate (reduce likelihood or impact with controls), transfer (share the financial impact with a third party), avoid (stop or change the activity that creates the risk) or accept (knowingly bear the risk). None is better in general. The right choice is the one that brings residual risk within the risk appetite at a cost proportionate to the risk it removes.

What decides the choice is this organization's risk appetite, the business impact at stake and the cost of each response. Any other input to the analysis is useful only insofar as it tells you about those three things for this organization.

Responses are often combined on one risk. A control lowers likelihood, insurance absorbs part of the remaining financial loss and the owner accepts what is left. The test is applied to the combination: the residual risk left by all the responses together must be within appetite. Each response does not need to reach appetite on its own, and sizing insurance to the full untreated loss double-counts the control.

A mandated control changes the analysis. When a law, regulation or contract requires a specific control, the main exposure becomes noncompliance itself. The responses that resolve it are to implement the required control (mitigate) or to stop the regulated activity (avoid). Choosing to continue without the control does not become compliance by being approved or recorded, at whatever level; it only documents that the organization is in breach, so it is not a response the security manager recommends. An acceptance made before the requirement existed was a decision about a different exposure.

Risk is treated until it is within appetite, not until it reaches zero. Risk appetite is the amount and type of risk senior management is willing to pursue or retain in pursuit of its objectives; it is set at enterprise level by the board and executive management. Risk tolerance translates appetite into the acceptable deviation for a specific objective, sometimes for a stated period, which gives managers a practical threshold to monitor against.

Tolerance and acceptance are easy to confuse. A tolerance is granted by the governing body (or under its delegation) and defines how far a particular objective may deviate from appetite, often for a limited time; the enterprise appetite itself is unchanged. An acceptance is an owner's decision about one specific residual risk, made within the room that appetite and tolerance allow; it cannot create that room. For example, a board that lets a newly acquired subsidiary run below group identity standards for its first quarter after closing has set a tolerance, not accepted a risk.

Once residual risk is within appetite, further treatment is usually poor value. Money and effort produce more value when they go to risks that are still outside appetite. Security spending stays aligned with enterprise priorities only if the target is appetite, not perfection.

A control is justified when its total cost over its life is less than the reduction in expected loss it delivers, and when the response as a whole still brings residual risk within appetite. Both tests matter. Cost-benefit ranks the options that meet the target; it does not override the target.

Measure both sides correctly.

• Cost is the total cost of ownership over the control's life: acquisition or licence, implementation, staffing, operation, maintenance and any productivity impact on the business.
• Benefit is the reduction in expected loss: typically annualized loss expectancy (ALE) before the control minus ALE after it, where ALE is single loss expectancy multiplied by the annual rate of occurrence. A control changes how likely or how damaging an event is, so its benefit is the change in that expectation.
• Affordability is a separate question from value: whether the money exists is decided by budget, whether the control is worth it is decided by the comparison above.

Worked example. A risk has an expected annual loss of 500,000 and an appetite of 150,000. Control A cuts the loss to 100,000 for 250,000 a year: it removes 400,000 (net benefit 150,000) and leaves 100,000, within appetite. Control B cuts the loss to 200,000 for 50,000 a year: it removes 300,000 (net benefit 250,000) but leaves 200,000, above appetite. B has the larger net benefit, yet only A meets the target, so A (or B combined with another response that closes the gap) is the recommendation.

When a control fails the cost test but the risk is above appetite, neither implementing it nor accepting the risk satisfies both tests. The manager should look for a cheaper control, a combination (a partial control plus transfer), or avoidance, and escalate to senior management if no option meets both. Declining a control is justified on risk-and-cost grounds: its lifetime cost exceeds the loss it removes and the residual risk without it is within appetite. The justification is recorded with the risk so the decision can be revisited when costs or exposure change.

Transferring a risk through insurance or outsourcing shares part of its financial impact; accountability for the risk stays with the organization, and so does the entry in the risk register. Customers, regulators and the board still hold the organization responsible for its data and services, whoever pays the bills or runs the controls.

Insurance. Cyber policies typically cover breach response costs, such as notification, forensic investigation and legal advice, and often business interruption. They cannot restore lost customer trust or brand reputation, and regulatory fines are uninsurable in many jurisdictions. So when the factor pushing a risk above appetite is reputational, transfer barely moves it; the response has to act on the event itself, reducing its likelihood or limiting how much harm it can do, rather than on paying for its aftermath.

Outsourcing. Moving an activity to a provider moves the operation of controls, not the ownership of the risk. Three consequences follow:

• The risk stays in the register and is re-rated, with provider oversight (contract security terms, right to audit, attestation renewals, periodic reviews) recorded as a control. Closing the entry, or moving it to a vendor list only, hides a business risk that now has a new dependency.
• A provider's certification or attestation report is a point-in-time snapshot. A lower residual rating is justified only while the oversight that supports it continues.
• Contractual liability is usually capped and purely financial; it compensates for a loss but does not make the loss less likely. Whenever new evidence changes what is known about a provider's controls, the rating changes with it, and the updated exposure goes to the risk owner, whose options include contractual remedies, added measures or exit.

Supplier and third-party management as a programme activity is covered in domain 3; here the point is how transfer affects the risk decision and the register.

Avoidance removes a risk by ending or changing the activity that creates it; acceptance keeps the risk and records a deliberate, authorized decision to bear it. They sit at opposite ends of the response range, and both are often misapplied.

Avoidance

Avoidance fits when the activity is of low value, when a cheap alternative exists, or when the risk comes from one design choice the business does not actually need. Declining to expand into a market whose data-residency rules the organization cannot meet, switching off a remote-administration feature that no one uses, or dropping an optional integration that would open the core finance system to a partner network are all avoidance. The business objective survives; the risky element does not. Accepting a high risk on a low-value activity gets the logic backwards.

Acceptance

A valid acceptance has five properties:

• Authorized: signed by a risk owner whose authority covers everything the loss would affect. A department head can accept risks confined to the department within delegated limits; a risk with enterprise-wide impact needs senior management. The security manager and internal audit do not accept risk on the business's behalf (audit would also lose its independence).
• Documented: recorded in the register with the basis for the decision. An accepted risk is still a risk; it is never removed from the register or hidden from reporting.
• Time-bound: carries a review or expiry date.
• Conditional: states the controls the decision relies on. If those conditions were never met, the residual risk the owner accepted is not the risk that exists. The acceptance no longer describes reality, and any further decision has to be made by the owner on the accurate residual risk.
• Revisited: re-evaluated at expiry or when circumstances change, such as a new regulation or a slipped remediation date.

Aggregation can make individually valid acceptances unacceptable together. If several units each accept, within their own limits, risks that stem from the same platform and could materialize together, the enterprise may be bearing more than its appetite. The security manager's job is to make the combined exposure visible to the management level whose authority covers the total; that level decides how the aggregate is treated.

A compensating control is an alternative control that meets the intent of a requirement the organization cannot implement as written, and it is acceptable only if it addresses the same risk as the requirement it replaces. The test is about the risk, not the paperwork: compare what the original requirement was meant to prevent or detect with what the alternative actually prevents or detects. A control aimed at a different threat leaves the original risk untreated, however well it is documented.

The security exception process is how the organization handles approved departures from policy or standards. A sound process has these steps:

1. The business submits a request stating the requirement, the business need and the duration.
2. The security manager assesses the risk and the need with the data or risk owner: what information is affected, what exposure the deviation creates and whether the need could be met another way. The decision is based on this assessment.
3. The owner approves, refuses or approves with compensating controls, within their authority.
4. The exception is recorded with an expiry date, after which it must be reviewed again. Without an expiry, a short-term exception silently becomes permanent.
5. Exceptions are tracked and reported, and their trends are analysed.

Exception trends are a signal about the standard. When a large share of exceptions concern the same requirement and are renewed repeatedly, the standard may be unworkable. The first step is to analyse why the requirement draws so many exceptions; the outcome may be a revised standard, a different technical solution or stricter handling.

A risk owner is the business manager accountable for a risk, with the authority to decide and fund its treatment and to accept what remains; a control owner is the person accountable for a specific control operating as designed. Ownership follows business accountability and authority, not technical knowledge or who runs the servers. One risk usually relies on several controls, each with its own control owner.

The security team should not own the business's risks. If the information security manager owns every cyber risk, treatment is decided by people who do not bear the impact, and decisions lose their link to business budgets and priorities. Expertise in analysing a risk is not authority to accept or fund it. Ownership sits with whoever answers for the business outcome the risk threatens.

Link controls to the risks they treat. A control owner who changes a control (for example, a database administrator turning off audit logging to save storage) can silently push a risk above appetite. The durable fix is process-level: record which risks each control treats, and make change approval check that link, so the risk impact is assessed and the risk owner is informed before the change goes ahead. Each role keeps its own decision. Communicating and monitoring these responsibilities across the organization is part of the manager's job.

A risk treatment plan turns a response decision into action by assigning each action an owner, a due date and resources, and by stating the target residual rating the work should achieve. Choosing a response is only a decision; the plan is what makes it happen and what gives a basis for tracking and reporting.

For monitoring treatment, the most useful register fields are the planned action, its owner, its due date and the target rating, alongside the current residual rating. Together they answer the two monitoring questions: is the treatment on time, and did it reach its goal?

The register must reflect controls actually in place. A common failure is showing a risk at the rating it will have after treatment while that treatment has not yet happened. Funding requests, escalation and interim measures all depend on accurate information, so the first step is to correct the rating to the current controls and inform the risk owner; escalating with a rating that assumes the work is done understates the urgency. Overdue treatment is reported, not silently re-dated.

Percentage complete is a weak status measure. Counting completed actions treats every action as equal. When the outstanding action is the one that delivers most of the risk reduction, a high completion figure can sit alongside exposure that has barely moved. Reports should show the current residual rating against the target and name the delayed action, so the owner can decide on interim measures.

Testing whether treatment worked

To confirm that treatment reduced a risk as planned, test that the control operates effectively and then re-rate the residual risk against the target in the treatment plan. Implementing a control is not the same as reducing risk; the evidence has to come from the control's actual operation measured against the risk it was meant to treat.

Design versus operating effectiveness. A control can exist and run on schedule while the step that actually reduces risk never happens. Nightly backups that report success are of little value against a ransomware scenario if restores are never tested and one critical system's backups turn out to be unreadable: residual risk is still near its inherent level and the register's rating must be corrected. The fix targets the step that fails.

Activity metrics do not measure effectiveness. Volume figures such as how many alerts a tool raised or how many items it processed move with tuning and workload, and say nothing about what the control misses. Effectiveness is judged against the risk scenario: has the exposure fallen to its target?

When a control operates but residual risk is still above target, the shortfall is in the design or scope of the treatment, not its execution. The gap goes to the risk owner, who can add or change treatment or accept the remainder within their authority. The register keeps the target and shows the gap until the owner decides. Deciding whether controls are appropriate and manage risk to an acceptable level is a recurring task, not a one-off check at go-live; control testing as a programme activity is covered in domain 3.

A key risk indicator (KRI) is a metric that signals rising exposure for a specific risk early enough for management to act, with thresholds tied to risk appetite and a named owner who must respond when a threshold is crossed. Good KRIs are leading rather than lagging: for the risk of fraudulent supplier payments, the number of supplier bank-detail changes processed without call-back verification rises before money is lost, whereas the value of confirmed fraudulent payments reports damage already done. An indicator earns the name only if it moves before the loss and is specific to the risk it watches.

An indicator without thresholds and accountability is just a number. What turns a metric into a control is a threshold derived from risk appetite and a named owner who must respond when it is crossed; together they create the obligation to act.

Report to senior management in business terms, against appetite. The board and executive committees need to know whether the organization is within the risk it agreed to bear and which way that is moving, so the core content is the risks outside appetite, their potential business impact, the decisions required and the trend over time (for example, the number of risks above appetite each quarter). Operational metrics belong in management reporting below that level.

Escalate undecided risk above appetite. A risk owner cannot leave a risk above appetite both untreated and unaccepted. Decisions belong to whoever has the authority for them, so the manager escalates through the defined governance path to the senior management level that set the appetite, which can direct treatment or, within its authority, accept.

When the normal reporting line has a conflict of interest in a risk, the manager uses the independent escalation channel that governance provides, such as direct access to the risk or audit committee. Escalation stays inside the organization's governance structure and the manager stays within their own authority.