So I had the benefit of a heads of audit course considering IT assurance last week. It was a good course and there were lots of ideas for me to take away. What came across most strongly for me was the fact that internal audit’s IT assurance work has not really moved on much since I was a junior auditor.
What I mean by this is that IT assurance is conceptually behind. As I don’t believe in general internal audit work focusing on compliance and preventative and authorisation controls (the world is just much too complex and difficult to be controlled in this manner), so I don’t for IT controls; the IT world has moved on. IT assurance is no longer about a moat and castle approach, because IT is not like that. Modern IT to my view is about managing risk and accepting failure. i.e. there will be data loss, there will be hacking, there will be problems.
IT is different to most sorts of risk, as once you have a hole in the system, the whole lot can be compromised. I think of IT risk as being like an ocean liner, if a single porthole is left open, the whole lot is liable to sink. This is not like a physical risk (fire takes time to transfer from site to site), reputational risk takes time to take its toll, business risk takes time to spread from business unit to business unit.
So back to IT assurance, if the model of prevention and managing risk to nil and preventing attacks is gone, perhaps it is about better detection and event management? Having an appetite for IT risk is something we auditors don’t like to consider. We like the neat idea of all passwords being kept secret or no-one ever leaking data or being socially engineered to give access, or all coding to be perfect and not allow unauthorised access. Most companies, organisations, and individuals cannot afford such control and this level of control, if you want to speak to the outside world with your IT (which all organisations need to), is simply not possible in any case.
So I think we as internal auditors need a new paradigm for IT assurance, we need to think about it in risk management terms and we need to think about risk appetite. Can we segment our client’s data? Can we have zones of protection? Can we be clearer about how data and other IT assets are managed? Can we consider how computer systems will cope with disaster and recovery (which ones need critical back up etc)? For IT assurance is not about poking holes in our clients’ IT systems, for there will be holes, and the better and more technically savvy we are as auditors, the more we will see the holes. Just as the better we understand business management, specialist areas we audit, and our client’s businesses, we will see greater holes in the management effort. So can we move on and deal with IT audit in the same way we do for general business risk and not aim for perfect, but have an analytical view of priorities and what needs doing, compared to the cost and effort of doing so and the relevance or criticality to business objectives?
The other interesting thing about IT assurance is that we are still asking ourselves the same questions. Do we outsource or not? This seems such a binary way of thinking about IT assurance and also seems to let ourselves off the hook. For all auditors should understand IT, I studied for the UK IIA’s ITAC qualification because I felt I should know about IT for any audit. So what would I outsource? Not general IT assurance, for a good core audit team should be able to do this in any case. I think it should be the specialist IT and technical knowledge. It’s too expensive for any team to maintain on its own. Technical IT assurance makes no sense on its own however. It does not have the wider context-dependent business knowledge to understand the context for IT.
So what’s the solution? I think the solution is to combine a good IT-savvy internal audit function with specialist technical support. We also need to focus less on prevention and control and more about management of IT risk within an appetite. It is difficult to assess and assure IT risk, simply because a single coding error can make an entire system open to loss and risk. So when we next consider the porthole left open on the boat, let’s focus less on bolting it shut, but more on how we will detect its opening and manage the resulting flood!