Learn how to choose, authorise, document and verify risk treatment decisions. Explore avoidance, reduction, risk sharing and acceptance with a realistic fintech case study.
Risk assessments help an organisation understand what could go wrong, how serious the consequences could be, and whether the exposure sits within its approved boundaries. Risk treatment is the next step: deciding what to do about the risk, implementing an appropriate response and verifying the result.
Suppose a fintech company discovers that an important payment service relies on a single third-party provider. The business cannot simply label the risk “high” and move on. Someone must decide whether to change the business activity, introduce resilience measures, share some consequences contractually, or retain the remaining exposure through an authorised decision.
Risk treatment is therefore both a business decision and a governance process. This guide explains the common treatment options, the evidence a GRC analyst should gather, how ownership and approval differ, and what effective treatment records look like.
A risk register without clear decisions becomes a catalogue of concerns. Effective treatment connects an assessed risk to a decision, an accountable owner, a practical action, resources, a deadline, a monitoring approach and evidence of completion.
The objective is not necessarily to eliminate every risk. Organisations need to take risk to meet their objectives. Treatment should be proportionate to the likely consequences, available resources, legal and contractual obligations, approved risk appetite and the organisation's ability to implement a response.
ISO 31000:2018 describes a broader set of treatment approaches, including removing risk sources, changing likelihood or consequences, sharing risk, retaining risk and sometimes taking more risk to pursue opportunity. For everyday GRC practice, these are often grouped into four familiar categories: avoid, reduce, transfer/share and accept. The labels are useful shorthand, not a claim that every framework uses an identical four-part taxonomy.
Avoidance means not starting, stopping or materially changing the activity that creates a particular exposure.
Example: A retailer decides not to launch a payment feature that would require it to store sensitive payment details until it can use a suitable third-party payment solution. It removes the risky design choice rather than relying on more controls around that design.
Avoidance is worth considering when the exposure is outside appetite, an acceptable treatment is unavailable, an activity is not necessary to meet objectives, or continuing would create an unacceptable compliance or safety concern.
Trade-off: Avoidance may sacrifice revenue, service capabilities or speed. It can also generate other risks. For example, withdrawing a service without an orderly transition could harm customers.
What to document: The activity being avoided; the risk being addressed; the business impact of stopping it; the accountable decision-maker; implementation requirements and confirmation that the risky activity has actually ceased.
Reduction, also called mitigation, means introducing or improving controls that lower likelihood, impact or another dimension of exposure under the organisation's assessment method.
Example: A SaaS company identifies that privileged accounts do not consistently use phishing-resistant authentication. The proposed response includes stronger authentication, access reviews and monitoring. These controls aim to lower the likelihood of account compromise and improve detection and containment.
Controls might be preventive (reduce the likelihood of a harmful event), detective (help identify it) or corrective and recovery-focused (limit consequences or support restoration). Some controls serve multiple purposes.
Do not assume a control is effective merely because it has been purchased or documented. An endpoint management tool that is installed but not covering critical devices may not produce the expected reduction in risk.
A credible mitigation plan identifies:
Current/residual risk means exposure that remains after existing controls. Target risk is the intended exposure following proposed treatment. They should not be treated as the same figure before the action is completed and its effect has been assessed.
Risk sharing or transfer shifts or distributes particular responsibilities, costs or consequences through arrangements such as insurance, contracts or outsourcing.
Example: A firm purchases cyber insurance to help cover certain financial losses from specified incidents. It may also negotiate recovery commitments and liability clauses with a technology provider.
These arrangements can change the financial consequences or allocate certain duties, but they do not make the underlying event impossible. Insurance does not prevent a data breach; outsourcing does not automatically remove the firm's oversight responsibilities. Policies have exclusions, limits and conditions, and contractual remedies may take time to enforce.
Before recommending this option, examine coverage, exclusions, deductibles, limits, counterparty financial strength, contractual enforceability, residual operational exposure and any obligations that remain with the organisation.
What to document: What consequences are shared, with whom, under which terms, which exposures remain, and who monitors the arrangement.
Risk acceptance is an informed decision to retain an exposure, usually because it is within approved acceptance criteria or because an appropriately authorised exception has been granted under the organisation's governance rules.
Example: A small internal system has a low-impact availability risk. The estimated cost and operational disruption of building full redundancy may exceed the expected benefit. If the exposure is within approved boundaries, the accountable owner may accept it with periodic review.
Acceptance is not the same as doing nothing. An acceptance record should identify the exposure, rationale, supporting evidence, accountable owner, authorised approver, conditions, monitoring arrangements and review or expiry date.
An out-of-appetite risk is not automatically acceptable because an IT manager has verbally agreed to live with it. Check the organisation's delegation of authority. Some exposures require a risk committee, executive approval or a formally approved exception. Legal and regulatory duties cannot be waived by a risk acceptance form.
There may also be cases where retaining some risk is a deliberate part of pursuing an opportunity. The decision still needs to align with approved authority, business objectives and other constraints.
Treatment selection is rarely a mechanical exercise. An analyst should help compare credible alternatives rather than presuming that the lowest theoretical risk is always the best decision.
| Decision factor | Questions to ask |
|---|---|
| Exposure and appetite | Is the current exposure within approved limits? What could change? |
| Business impact | What happens if the activity is stopped or the control is introduced? |
| Effectiveness | How much might each option change likelihood or consequence? What evidence supports the estimate? |
| Feasibility | What will it cost, how long will it take, and what dependencies exist? |
| Obligations | Are there legal, regulatory or contractual minimum requirements? |
| Authority | Who owns the risk? Who can authorise each response or exception? |
| Remaining exposure | What residual and target risk remains after the selected actions? |
| Monitoring | What indicators, test results or events would trigger reassessment? |
Several options can be used together. A retailer might reduce an outage risk with redundant infrastructure, share some resulting financial exposure through a contract and accept the remaining downtime risk once it is within tolerance.
The risk owner is accountable for the risk and for ensuring an appropriate response is considered and followed through. The treatment owner may be the technical or operational person assigned to implement a measure. The approval authority is whoever the organisation's governance framework empowers to approve the treatment or acceptance decision. These roles may overlap, but should not be assumed to be identical.
A GRC analyst generally supports the process by validating risk information, challenging assumptions, comparing options, checking appetite and policy requirements, coordinating documentation, tracking actions and escalating exceptions. The analyst should not independently accept a business risk unless the organisation has explicitly delegated that authority.
Where an exposure is acute or an incident is already occurring, operational incident response may be necessary immediately rather than waiting for a routine governance meeting.
Fictional organisation: Northbridge Payments, a UK fintech. Its payment service depends on one external processing provider. The vendor experienced two lengthy outages in the last quarter. Operations has identified a plausible future service interruption affecting customer transactions, reconciliation and reputation.
Northbridge's illustrative five-by-five methodology records the following:
| Attribute | Current assessment |
|---|---|
| Risk statement | If the sole processing provider becomes unavailable, customer payment services may be interrupted, resulting in financial loss, failed transactions and reputational damage. |
| Existing controls | Supplier SLA, basic alerting and manual incident communications |
| Current likelihood | 4 / 5 |
| Current impact | 4 / 5 |
| Current residual score | 16 / 25 (critical in this fictional matrix) |
| Approved acceptance boundary | Maximum residual score of 10 for this risk category |
| Risk owner | Director of Payments Operations |
The score is outside the stated acceptance boundary, assuming the assessment is valid. The score is an ordinal prioritisation measure, not a precise loss probability.
| Option | Potential benefit | Key limitation |
|---|---|---|
| Avoid: discontinue affected product | Removes the dependency associated with that activity | Major disruption to customers and revenue |
| Reduce: implement a tested alternative processor and failover plan | Could reduce interruption likelihood or consequence | Requires integration, testing, operational capacity and funding |
| Share: negotiate stronger contractual remedies and examine insurance | May offset specified financial consequences | Does not ensure payment continuity |
| Accept: retain current arrangements | No immediate implementation cost | Outside the approved limit; requires formal authority, if exceptions are permitted |
The GRC analyst recommends that the risk owner seek approval to build and test a secondary-processing capability, alongside improved monitoring and a documented continuity procedure. The risk owner should also evaluate contract terms, but not treat them as a substitute for resilience.
Illustrative target: Likelihood 2 / 5 and impact 4 / 5, giving a target score of 8 / 25 after the changes have been implemented and validated. This is a planning assumption, not an achieved risk reduction. A verified failover test and evidence of readiness would be needed before revising the current assessment.
Until then, the risk remains scored at 16 and must be escalated through the out-of-appetite process. If the business must continue operating during implementation, the designated authority must decide whether the policy permits a time-limited exception with documented compensating measures, monitoring and expiry. An exception does not itself lower the current risk score.
| Field | Example entry |
|---|---|
| Risk ID | ERM-024 |
| Treatment strategy | Reduce, supported by contractual risk sharing |
| Action | Build, test and operationalise alternate payment processing |
| Risk owner | Director of Payments Operations |
| Treatment owner | Engineering Manager |
| Approval authority | Executive Risk Committee under the fictional delegation schedule |
| Due date | 90 days after approval |
| Interim measures | Enhanced vendor monitoring, response runbook, weekly exposure review |
| Verification evidence | Failover test results, procedure approval, monitoring configuration |
| Current score | 16 / 25 |
| Target score | 8 / 25 (unverified estimate) |
| Status | Planned; current exposure remains outside appetite |
| Review trigger | Missed milestone, new major outage, ineffective failover test |
This illustrates why a treatment plan needs more than a single column labelled “Mitigate”. It must make ownership, decisions, delivery and verification visible.
An effective acceptance record should enable a reviewer to answer: what was accepted, why, by whom, under what authority, for how long, and with what conditions?
A useful minimum record includes the risk reference, date, scenario and consequences; current controls and assessment; appetite comparison; options considered; acceptance rationale; business impact of alternatives; required approval and decision; compensating controls; expiry or review date; and clear conditions for reassessment.
Where temporary acceptance of exposure outside appetite is allowed, call it an exception only if that matches the organisation's policy. The distinction between risk acceptance, policy exception and risk waiver varies by organisation. Do not infer permission merely from a template's existence.
A completed task is not necessarily an effective treatment. For example, deploying a new authentication policy is an implementation milestone. Evidence that the policy covers the intended accounts, blocks unsafe sign-in methods and is monitored is stronger evidence of effectiveness.
Verify both implementation and outcome, using suitable tests and measures:
In some cases, a control is correctly implemented but does not reduce exposure as expected. The risk owner then needs to reconsider the treatment, not merely close the action because a project milestone was achieved.
Calling every response “mitigation”. Avoidance, retention and sharing are distinct strategies; use the terms accurately.
Assuming insurance transfers all risk. Cover may transfer some financial consequences but not reputation, customer harm or retained legal responsibilities.
Treating target risk as current risk. Projected benefits do not count as achieved control effectiveness.
Allowing the analyst to approve the business risk. Advisory support and decision authority are different responsibilities.
Accepting risk without evidence or a review date. Conditions may change and informal approval may be outside delegated authority.
Ignoring the cost of treatment. The best response balances risk reduction, obligations, feasibility and business objectives.
Closing an action without testing its effect. Implementation and effectiveness are separate matters.
Risk treatment is the process of selecting and carrying out an informed response to assessed risk. The common options are avoidance, reduction, sharing or transfer of consequences, and informed acceptance. More than one option may be appropriate.
A GRC analyst helps ensure the decision is supported by evidence, consistent with appetite and obligations, made by an authorised person, and tracked until its effectiveness can be demonstrated. A plan is not a control, an approval is not remediation, and a target score is not a verified residual score.
Next recommended resource: Risk Monitoring, Key Risk Indicators and Reporting. After selecting treatment, the next task is to monitor implementation, changing exposure and management actions.
Related resources: Risk Appetite vs Risk Tolerance: Understanding Limits, Thresholds and Breaches; Inherent Risk vs Residual Risk; and the ERM Toolkit and Quick-Start Guide.
This article provides educational guidance and uses fictional organisational policies and examples, not a universal approval hierarchy or mandatory remediation timescale. Applicable legal and regulatory duties depend on the organisation and jurisdiction.