Background: For a long time there has been a battle of expectations between risk management and IT management on who needs to articulate and express IT management’s risk appetite and risk tolerance statements. For reasons not quite known to me (but I can make a decent guess that it is because, as some put it: “if you don’t articulate the high level statements, no one will”) the IT management has fought tooth and nail that it is risk management’s duty to tell IT management what the risk appetite statements should be.

Risk management position has always been that we cannot tell those that take their risks what they risk appetite should be. It is, after all, the management’s actions that clearly define just what their appetite and tolerance is.

For the purposes of making sure we are all aligned, here’s what is understood under the two terms.

Risk appetite: This is your general, high level expression of what you are, or aren’t willing to risk in order to reach your goal. Get your goodies. Join the dark side to get your hot little hands on their cookies. Whatever it is that your long term goal is. An example of a risk appetite would be: I’m happy to risk 10% of everything I have in order to get at least 20% profit. Otherwise I’m not willing to play.

Risk tolerance: Now this is where things get interesting. This is what people are often understanding under risk appetite. Let’s say that you come across this once in a lifetime opportunity to win big. If you succeed, you will be the ruler of the world, the big cookie monster, the one, the only, blah blah blah. Price if you fail? Nothing huge, just your first born. Seeing the massive payout if you win (and let’s say that the odds are 80:20 in your favour) the risk seems manageable. And your firstborn just won’t let you sleep at night, so it sounds like a win-win situation. Many organisations usually take big risks on certain projects, hoping to strike big. (And employees cynically know they can at least pad their resume with something large in case it fails.)

So, as you can already guess, the end result of it all was that I ended up writing a few high level risk appetite statements:

  1. Process Integration

  2. Pace of Change

  3. Business resiliency and recovery profile

  4. Sourcing Partnerships

  5. Technology Service Model

1. Process integration (Regional / Global)

Appetite Statement: Processes will be integrated where the result is reduction in complexity that is not outweighed by the increase in rigidity of the operation of the processes.

Rationale: Some processes can be integrated without resultant increase in maintenance of the systems supporting those processes. If a process integration results in increase in rigidity (i.e. a change in process integration cannot be done for a particular part of the organisation without impacting other parts of the organisation) then that should be treated as increase in complexity and addressed in that fashion (see #3).

2. Pace of change

Appetite Statement: Pace of change will be within the reasonable range of the ability to absorb and process the change.

Rationale: If the pace of change far exceeds the ability to absorb then the change results will be counterproductive and the organisation will lag behind the competition. If the pace falls short of the ability to absorb then the organisation will not reach its full potential and will lag behind the competition.

3. Business resiliency and recovery profile

Appetite Statement: We will embark on projects that reduce complexity. Projects and undertakings that increase complexity will need approval by the relevant Executive Committee.

Rationale: Small increase in business complexity results in great reduction of business resiliency and increase in the recovery time. A project that increases complexity should be vetted by the highest possible authority to ensure that the increase in complexity does not go unchecked by all affected departments.

4. Sourcing partnerships

Appetite Statement: All sourcing partnerships will be reviewed based on the full impact of the partnership. Entering a sourcing partnership must be complete with an exit strategy that is proportionate to the size of the impact to the organisation.

Rationale: “The bigger they are, the harder they fall” is particularly true of business partnerships. Whilst the Organisation must be fully committed to a business partnership to make it work, it must also keep an exit strategy current in case the partnership fails for any reason.

5. Technology service model

Appetite Statement: Only service models that are flexible, agile, easy to enter and easy to exit should be considered. Service models that tie the Organisation into long-term relationships increase complexity and will be treated as such (see #3).

Rationale: Service models that don’t allow the Organisation to maintain flexibility will by nature increase complexity and rigidity. Rigid systems are fragile and require additional care and cost to maintain, increasing operating costs and recovery time in the event of failure.