IT GRC, what's the difference?
Well, in my view they're the same at a theoretical level, but very different at a practical level. Let me explain. When people solve problems, the vast majority always looks for concrete things to solve. The more concrete things are to look at, the better it seems to be. There is even a tendency to prefer practical. Theoretical, or even worse academic, is a bad thing. Of course, it isn't. Practical can also be working very hard on the wrong things.
So, we look at incidents that happen. We look at whether the roles in a system have been configured properly to ensure segregation of duties (SoD). We look at whether policies are implemented correctly or not. Clearly, this is dramatically simpler in IT than in business. We can simply examine an IT system and check SoD, we can go into a server and verify whether the latest patches have been applied.
In business, in general, this is more complex. Policies are harder to verify, and require judgment rather than show hard numbers. There is a difference in determining whether someone understands the Code of Conduct and applies it, or whether the browser that is used has the latest security fix.
So rather than focus on the things that really matter, people tend to focus on the concrete things, because these can be solved. So, we spend a fortune to correct SoD, but do not know whether users have been properly trained in the ERP system. Which risk is higher? Which risk is easier to solve? Let me rephrase that, which risk is easier to measure, prove that it exists? And therefore easier to solve (in this context: get budget for). Don't get me wrong; of course threat management, incident management are hugely important processes. But only because they are in the bigger context; first understand this bigger context, before investing.
Clearly, there is no conceptual difference between IT GRC and enterprise GRC. Both use the same concepts; have similar use cases and challenges. However, in IT GRC it is much easier to find concrete issues, it is much easier to get lost in the details, rather than focus on the risks that really matter. Use a top-down approach, and combine it with a bottom-up approach looking at data.