Risk acceptance decision flowchart

What the risk acceptance decision process is

Acceptance is the risk treatment that needs no budget, no project and nobody to do anything, which is why it is the one organisations arrive at by accident. A risk sits in the register, the control is never funded, and two review cycles later the entry is described as accepted although nobody decided anything and no name is against it. Drawing acceptance as a decision tree is what separates a risk somebody chose to carry from a risk everybody stopped looking at.

This page is a decision tree, not a process map. It answers one question - should this residual risk be accepted, and who is authorised to accept it - by working through the tests in order and ending at one of five named outcomes rather than funnelling back into a single happy path. It does not describe the surrounding cycle. Identification, scoring, control effectiveness and the review loop belong to the Risk assessment process flowchart, which is the cross-functional map of what happens next and who does it. Use that page for the end-to-end procedure; use this one for the moment of judgement inside it, where one option is chosen over another and somebody has to sign.

The four bands down the left name who answers each question rather than who does the work: risk owner, risk manager, legal and compliance, accepting authority. The tree is deliberately unyielding in two places. A breach of a legal, regulatory or contractual obligation never reaches an approver at all, because non-compliance is not the organisation's to accept, so it exits straight to remediation. And a residual risk outside appetite cannot be accepted permanently: it needs a compensating control and an expiry date, and it is carried as a time-boxed exception by the risk committee rather than signed away. Those are the two branches an auditor looks for.

What this flowchart covers

In this template

• Four decision-rights bands - Risk owner, Risk manager, Legal and compliance, Accepting authority - across five stages: Proposal, Treatment test, Eligibility test, Conditions, and Authority and record.
• Two gates before acceptance is even on the table: "Treatment options evaluated?" returns an untested proposal to "Complete the treatment analysis", and "Treatment viable and proportionate?" exits Yes to "Treat rather than accept".
• "Breaches a legal or contractual duty?" in the Legal and compliance band, whose Yes branch goes to "Refuse acceptance and remediate" - the one exposure the chart never routes to an approver.
• "Residual risk within appetite?" split Within and Outside. Within continues to the conditions and authority tests; Outside goes to "Compensating control in place?", which either refuses acceptance outright or builds a time-boxed exception through "Confirm control and set expiry".
• Authority set by rating rather than by who is available: "Residual rating band?" sends Low/medium to "Manager holds delegated authority?" and High/critical to "Risk committee accepts residual risk?", so "Accept at manager level" and "Accept at executive level" are separate endpoints.
• "Acceptance time-bound with a review date?" with a No branch that sets an expiry before anything is signed, and five terminators in all: treat rather than accept, refuse acceptance and remediate, accept at manager level, accept at executive level, and accept temporarily until expiry.

When to use this template

• You are writing the acceptance or exception clause of a risk policy and need the tests written down rather than described in prose.
• Your register carries entries marked accepted with no signatory, no conditions and no expiry date, and you need acceptance to become an act rather than a default.
• You are setting delegation of authority for risk acceptance and want each rating band tied to a named level before the next argument about who signs.
• An auditor or certification body has asked who accepted a residual risk and on what basis - ISO/IEC 27001, for example, requires risk owners to approve the treatment plan and accept the residual information security risks.
• A team is asking for a security or policy exception and you need a repeatable test, with conditions and an expiry, instead of a case-by-case negotiation.

How it works

1. Rename the bands to your decision rights

   Replace Risk owner, Risk manager, Legal and compliance and Accepting authority with the roles you actually have. Keep the risk owner separate from the risk manager: one carries the consequence, the other runs the method and should not be the person signing. If your executive team and your risk committee are the same forum, merge those into one accepting authority rather than drawing a hand-off that never happens.

2. Write your appetite threshold onto the appetite test

   "Residual risk within appetite?" is the pivot of the whole chart, so put the threshold from your risk policy next to it - the score band, or the plain statement of what the organisation will and will not carry in money, downtime, harm or reputational terms. An appetite that lives only in a policy document gets approximated from memory, which is how the same exposure ends up inside appetite on one desk and outside it on another.

3. Map rating bands to named acceptance authorities

   Replace Low/medium and High/critical with your own score ranges and name who may sign at each. Two rules keep the branch honest: nobody accepts a risk on their own behalf when the acceptance is what unblocks their project, and the manager branch checks delegated authority explicitly rather than assuming seniority implies it. Anything above the manager's limit routes to the committee, which is what "Manager holds delegated authority?" is for.

4. Define what counts as a compensating control

   On the outside-appetite branch, the compensating control is the only thing standing between the exception and a refusal, so state the test. It has to be already operating rather than planned, evidenced rather than asserted, and it has to reduce the same exposure rather than a neighbouring one. Monitoring counts only if somebody is obliged to act on what it reports.

5. Cap the acceptance period and say what happens at expiry

   Put a maximum on the term rather than leaving it to the proposer - commonly no longer than the next scheduled review, and shorter for high-rated risks - and add event triggers such as an incident, a system change, a new contract or a change in the control itself. State that at expiry the acceptance lapses and the risk re-enters this tree, because an acceptance that rolls over silently is an open-ended one wearing a date.

6. Record the decision on the register, then keep one current version

   The output of the tree is a record: who accepted, at what band and under what delegated authority, the conditions and compensating control, the expiry and review date, and the treatment comparison that justified accepting instead of treating. Walk the finished chart through with risk, legal and whoever signs, correct it to what they actually do, then publish that revision and keep the earlier ones so anyone opening it later can tell which version they are reading.

Frequently asked questions

What is risk acceptance?

Risk acceptance is a decision to retain a residual risk knowingly rather than reduce, transfer or avoid it. ISO 31000 lists retaining the risk by informed decision among the treatment options, and the phrase to hold on to is "informed decision": the difference between accepting a risk and ignoring one is a named person with the authority to carry it, a record of what was known when they decided, and conditions attached. Acceptance is legitimate when treatment has been costed and judged disproportionate to the exposure. It is not legitimate as the thing that happens when nobody funds the control, which is why the first two decisions in this chart test the treatment analysis before acceptance is considered at all.

Who should be authorised to accept a risk?

Whoever is accountable for the consequence, at a level matched to the rating. Most organisations set this in a delegation schedule: a line or department manager for low and medium ratings, an executive owner or the risk committee for high and critical. Two safeguards matter more than where you draw the line. The chart checks delegated authority explicitly - "Manager holds delegated authority?" - rather than assuming seniority implies it, and anything above the limit escalates instead of being signed locally. And the accepting authority should not be the person for whom the acceptance is convenient: if the acceptance is what unblocks someone's project or budget, the decision belongs one level up.

Can you accept a risk that breaches a law, regulation or contract?

No. An organisation cannot decide to be non-compliant, so a known breach of a statutory, regulatory or contractual obligation is remediated rather than accepted, and in this chart that branch never reaches an approver - it exits to "Refuse acceptance and remediate". What can legitimately be time-boxed is the interim exposure while remediation runs: a plan with an owner and a date, an escalation to whoever needs to know, and legal advice on disclosure or notification obligations where they apply. Recording that as an accepted risk instead is the version auditors and regulators react badly to, because it documents a decision to carry a breach.

Should a risk acceptance have an expiry date?

Yes. An acceptance is a judgement about the exposure, the controls and the cost of treatment as they stood on one day, and all three drift. Give every acceptance a term and a review date, cap the term in policy rather than leaving it to the proposer, and make it shorter for higher ratings. Say explicitly what happens when it runs out: the acceptance lapses and the risk returns to this decision tree for a fresh answer, rather than rolling over on the nod. Add event triggers alongside the date - an incident, a system or supplier change, a new contract, or the compensating control being changed or removed - because those tell you the judgement is stale sooner than the calendar does.

How is this different from a risk assessment process flowchart?

They answer different questions. A risk assessment process flowchart is a cross-functional process map: it shows what happens next and who does it, from identification through scoring, control effectiveness and treatment to the review cycle. This page is a decision tree for one moment inside that process - the point where treatment has been costed and someone has to choose between treating and accepting. It has no tasks to hand off, only tests to answer from evidence, and it ends at five distinct outcomes rather than a closed record. If you are documenting the procedure, use the risk assessment process template. If you are settling who may accept what, on what conditions and until when, use this one.