Risk Appetite, Tolerance and Acceptance

Risk appetite, tolerance and acceptance. This lesson is about who decides how much risk an organisation will carry, who may accept a specific risk, and at what level. It builds directly on the risk response from the last lesson.

Start with a situation. A junior I-T manager tells you they have accepted the risk of leaving an internet-facing server unpatched, because patching it would cause downtime the business dislikes. The trade-off is genuinely real. The decision was theirs to announce, but the question the exam is testing is, was it theirs to make.

Because risk appetite, the amount and type of risk an organisation is willing to pursue in meeting its objectives, is a governance decision. It is set by the board, or by senior management on the board’s behalf. Everything below it operates within it. Every mitigate, transfer, accept or avoid decision is made against the appetite the board has defined.

Which is why appetite cannot be set by the I-T security manager, or by individual system owners. They make decisions within appetite. They do not decide how much risk the enterprise as a whole will carry. And audit evaluates whether decisions stay within appetite, but does not set it either.

The exam distinguishes two related terms, and questions turn on the difference. Appetite is broad and strategic, the overall level of risk the organisation will take. We are willing to accept moderate operational risk to enter new markets quickly. Tolerance is narrow and specific, the acceptable variation around a particular objective. A critical service may have no more than four hours of unplanned downtime per quarter before it breaches.

So tolerance operationalises appetite for a specific target. Appetite says how much risk in general. Tolerance says how far a specific measure may drift before it is out of bounds. Treating the two as synonyms is a reliable trap.

Now acceptance. As we saw in the risk lesson, accepting a risk is a legitimate response. What the exam tests hardest is something else: the authority to accept must match the size of the risk.

So think of it as a ladder. A small, local risk can be accepted by a local manager.

A significant risk needs a higher level of authority to accept it, someone who can answer for that magnitude.

And an enterprise-level risk must be accepted by senior management or the board. A team leader cannot accept an enterprise-level risk, exactly the principle from the findings lesson in Domain 1.

Which is why the junior manager’s acceptance is the finding, and notice why. Not because acceptance is wrong, and not because unpatched servers are always unacceptable. It is the finding because an internet-facing unpatched server may carry enterprise-level exposure, and a junior manager is not positioned to accept that on the organisation’s behalf. The right move is to escalate the acceptance to a level of authority that matches the risk.

So carry this away. When you see a risk accepted, do not ask only, was acceptance reasonable. Ask, was it accepted at the right level of authority, and within the board’s appetite.