At the moment I am working on a big GRC change project for a client and we are starting to think about software tools for control self assessments. The initial interest was to see if some of the existing in-house applications in use for other purposes, but we have discounted these because they do not adequately allow for the aggregation and analysis of results, nor do they enable effective tracking of open issues until closure (after all what is the point of reporting an area for improvement if you cannot be confident it has been dealt with?)

We are now in the process of looking for solutions that some of my other clients have used, adapted for the needs of this client. Here my advice is simple: What is the point of reinventing the wheel? Lets select something that works well elsewhere – our needs are not that different because this is about largely mechanical process of collecting a specific sort of information, categorizing it and then deciding what to do about it.

At the same time I have been working with another client on assurance mapping, focusing on several specific areas of interest to senior stakeholders. Here there was interest at first in me offering a standardized approach, standardized report – and ideally – a simple tool to use. The attraction of a standardized approach and a simple tool is clear, but my client has recognized – over the course of our work together – that force fitting a standard approach would not work for them.

In particular, my client recognized that the real purpose of asking me to work with them to map assurances was not really simply about mapping assurances, but to identify areas for improvement in areas where there had been question marks previously. In one specific area I was working on we have agreed to postpone the completion of an assurance map until, after: 1) we have resolved certain issues concerning the oversight accountability for the risk in question and: 2) we have held a workshop with key managers to resolve some specific areas of concern. That way, when we complete the assurance map, we will have some clear and agreed action areas to report on (rather than just a series of gaps). In addition, this approach, working pragmatically alongside management, has helped them understand the power of assurance mapping and the benefits it can deliver; increasing the chances it will be used for other areas and also on an ongoing basis (after all what is the point of assurance mapping if it is going to be just a “one off”?).

Here the conclusion is clear, simply following a standardized approach when a more complicated question is being addressed will not deliver the benefits being sought. I would sum this up with notion that its important to fit ready made solutions only where they actually fit the problem that needs addressing. This is true particularly where we are working on complex risk assurance questions. A specific pet topic of mine at the moment is the danger of applying a standardized approach to the measurement of risk culture. I will return to this in later blogs.