Assessing and addressing technology risk
One of my frustrations over the years has been the continuing practice of those involved in addressing technology (or IT) risk and related audit of seeing it in a silo.
About 15 years ago, I was on a team of practitioners developing guidance for auditors (the GAIT Methodology, which continues to be recommended guidance by the IIA). One of the team members was Jay Taylor, head of IT Audit for GM at that time (later their CRO). He said something that resonates today:
“There is no such thing as IT risk, only business risk.”
We should not be concerned specifically with risk to systems availability, access, security, etc. or even to information assets. What we should be concerned with is risk to the business and the achievement of its objectives.
Any technology risk assessment should be made in terms of the potential effect on the business, not any effect on IT assets or goals.
Yet, guidance from ISO, NIST, and FAIR continues to focus on the silo not the whole business. It does not enable risks arising from technology-related issues to be measured against technology-related rewards, or other sources of business risk. It doesn’t enable decisions to be made about where scarce resources are best invested: for example, addressing ransomware risks or the possibility of being late to market with new products. After answering such strategic questions and determining the level of resources that should be spent on addressing cyber, for example, it is time to look inside the silo and decide in more detail and specificity where those resources should be focused.
I addressed this in Making Business Sense of Technology Risk, in many ways my most difficult book to write and which should be eye-opening to many IT risk and audit practitioners. Fortunately, I had an all-star cast of practitioner reviewers!
But the world continues to focus on IT risk instead of business risk.
Consider a recent piece from KPMG: IT Internal Audit Planning for 2021. While it has some interesting and useful observations about what is inside the silo, it recommends that IT audit practitioners focus there instead of the larger business – the context within which IT operates and serves.
For example, KPMG says:
IT Internal Auditors must stay aware of, and align themselves to, the IT transformation activities across the organization to stay relevant.
While this is true, what is more important is for all internal auditors, not just those who specialize in technology, to understand how the business is transforming! Auditors (and risk practitioners) should look to the future and understand how technology can and should be deployed for current and future benefit.
In other words, understand the strategic plans and initiatives of the enterprise and then consider how technology is and will be used.
Only now can technology-related risks to the business be identified and assessed – in terms of achieving those strategic plans and related objectives.
XX
The other point I would make, which is overlooked by far too many, is that talking about “IT” is limiting. It is far better to talk about technology, which extends beyond the scope and control of IT management. Technology is being deployed in manufactured products as well as the equipment used to make them.
XX
Technology should not be assessed in a silo.
We should not be talking about IT audit planning but planning for the entire internal audit organization. Often, I had integrated teams of operational and technology auditors working on major system development projects. And… planning should be continuous.
Staffing needs to be done with care. You need people who can see the big (business picture) as well as people with the technical skills for the technology of today and tomorrow.
XX
I welcome your thoughts.
Wow. It’s hard to believe how little internal audit practice around technology seems to have moved since 2006/07. At that time you and Gene Kim were hammering out the final text that became GAIT out in Palm Springs around the pool during the CAE Conference.
Yes, KPMG’s point about alignment with transformation activities is important. It was one of the things we did at GM not because “leading edge” technology was being introduced, but because of the potential risk to the business the USE of the technology would introduce. Technology itself has no “risk”. So when VMWare was first introduced, it became a key piece of the processing environment that had to be understood and assessed by the audit team. The objective was to evaluate how the software, hardware and related procedures might impact the confidentiality, integrity or availability of our vehicle sales reporting to the public, for example.
I would love to see “Making Business Sense of Technology Risk” become required reading for every “IT audit” course in IIA and ISACA.
Jay, you have some good points but I must disagree with one. You say that technology itself has no risk. Actually, it does. Hackers can steal data, bother personnel and proprietary, which doesn’t impact the operation of the business at all. But the risk of data loss can put emplyees and customers at risk of identity theft. A risk to the company would only occur if the breach becomes known to the public. Pure and simple, this is strictly a technology risk – yet it needs to be addressed like any other risk.
Richard, I don’t understand how the theft of data doesn’t impact the operation of the business. Competitors can use IP to advance their competitive products; personnel data can be used in additional hacking that results in loss or disruption; and, employees can sue if the theft results in a loss to them.
Even if there is a ‘risk’ to technology that doesn’t affect the business, the question is whether there is a need for the business to invest to address it!
Thank you for posting. Absolutely true about aligning all risks with business goals.