Strategy audit

I've not seen much in the way of strategy audit, but it seems an interesting area (particularly for the auditor). Perhaps the reason that it is not subject to frequent audit is that it tends to be the domain of senior management, that don't want audit sniffing around.

Some questions I'd want to ask:

• Is the strategy formation (and update) process documented?
• Is there an up-to-date organisational strategy?
• Has the strategy been communicated to the right people?
• Are all the necessary inputs to strategy formation in place (market information, competitor information, technology information, internal information)? (this would use PESTLE, Porters 5 Forces, 9Ms, etc)
• Are the right people involved in strategy formation? (sales, marketing, finance, risk management, technology, research & development)
• Do the strategy formers have the right qualifications, experience and skill?
• Are there any training requirements? Are these being met?
• Does the strategy flow through from the single-line mission statement to more detailed objectives, and right down to individual performance objectives?
• Is there a feedback loop on performance that allows validation of the strategy?
• Is there a process to accommodate significant events into the strategy?

Single line journal report

Journal auditing can be hard work. Say you have a general ledger dump and you want to identify all journals to cash accounts. That's easy enough, just apply a filter to the account code. But then you've only got one side of the journal. To get both, you need to extract that filtered set of journals, then reapply to the original dataset as a join, matching on the journal identifier.

What would be really useful is a report from the accounting system that gives both sides of the journal entry in one line of the report. One column would should the account code debited, and another the account code credited. Applying filters to each of these columns makes it very easy to see where journals are going.

To get this work, the system would need to force all journals to be two-entry only equal and opposite (rather than those that say debit two accounts and credit one). But having such a rule would be not bad thing, as it would give a granularity of data in the ledger.

Net transaction view

Often, trying to understand what comprises the balance on a GL account can be challenging, particularly where there a lots of journal entries (e.g. reclassifications and reversing journals).

Reclassification and reversing journals should be linked on the system. The user should be able to pick up a line entry (in the case of a reclassification) or a double entry (for reversing journals) and then execute an action (e.g. change the account code or cost centre, or reverse, etc). Such an action should still go through the journal segregation of duty/authorisation process and supporting documentation be retained.

The advantage of a system that links entries on the GL is that it allows a "net transaction view", i.e. only showing where transactions ended up (not how they got there). The full audit trail is there on the system if needed, but the "net transaction view" allows the contents of the ledger to be more easily understood.

Almost certain

Should risk management cover events or outcomes that will almost certainly happen?

The appropriate definition of risk

Unhelpfully, there are lots of different definitions of risk. For example, "a risk" can mean "a potential event". What helps me is thinking about what people mean when they ask the question "what is the risk?": they mean "what is the probability and significance of the outcome". Therefore risk is the probability and level of impact associated with an event.

But should it just be "event"? In some circumstances it may be helpful to think in terms of outcomes, situations and occurrences. For example, having insufficient premises isn't something that fits the definition of an event, but rather a situation.

Working backwards from controls?

Where there are already controls in place, should the risk be added to the risk register?

For example, if an organisation is new to implementing risk management, is it appropriate to track back from the controls in place to ensure all controls and their corresponding risks are on the risk register?

Risk: how low do you go?

How complete does risk management need to be? How low (impact/probability) should you go? At what stage are you just making risk management bureaucratic? How do you evidence the consideration of this long tail without including it in the risk management process?

We think to ourselves "this risk is too low (impact/probability) to include in our risk management". But this undocumented thought is itself risk management.

Is there an opportunity to outsource risk management for low value risks? Such an outsourcing function would, based on business criteria and information provided to it, estimate the relevant low value risks to the business. This document can then be shared with the organisation for sense checking (and possible escalation of some risks into the core risk register).