Done right, a Governance, Risk and Compliance Management (GRC) program will be a valuable part of the executive toolkit and culture for your organization.
In working with clients we have come across GRC programs that are either: recently launched, under way, or old timers (in GRC years). What I’ve noticed is that even in the more extensive implementations there are only a few executive stakeholders that claim to have received that “big bang for the buck” in terms of understanding enterprise risk. In addition, some programs are challenged by turnover of GRC champions and suffer distraction around new shiny technology objects. Sometimes it’s dwindled to “oh yeah, what about that GRC thing?” Why is such promising technology challenged with maintaining energy and hitting the eventual home-run with executives for whom it was supposed to appeal?
In short, the problem is the same as with any other technology that is designed to answer big questions; It’s not aligned with executive goals, executive decision making, and business enablement opportunities.
In my career I’ve seen and heard similar stories with other ground-breaking technologies: Knowledge-Based Management Systems, Customer Relationship Management, Content Management, SAP, Predictive Analytics – you name it. You have to drive the technology and not let the technology drive or shape you. Through my roles as technology analyst, engineer, engineering manager, security architect and chief security architect I learned valuable lessons around driving technology from the business layer, through the information layer, down to the systems design layer. Guess what? GRC is no different. One of my favorite bosses used to say “we have enough technology to launch a space shuttle – what are you going to do with it?”
…So how’s your GRC?
GRC as a “Risk Engine”
It is clear that GRC platforms are designed and packaged to truly collect and compare your risks. The diversity of components offered in GRC products match the goals of risk management by pulling together all the relevant drivers of risk. The data models are wired for risk management as well by factoring in context of risks. Here’s the catch – where did you set the scope?
You have to set the scope of a program to establish the stakeholders. There are big questions being asked in the field of risk management with hunger for timely information. You have to establish policies, governance, processes, controls testing and measurement to match. In addition, you have to focus on metrics for processes, key risk indicators, as well as top risk scenarios. What I’ve seen is scope set at one level but a mismatch of policies, controls, measures, and a lack of business aligned assets through which you determine impact and actual risk.
Watch out for this too – I’ve seen IT set as the scope while not all of IT policies and governance covered. Many times it’s really established as a security and personnel GRC. Don’t forget that if you are doing IT Risk you have to factor in risks that transcend security. Make sure your intended scope and actual deliverables are aligned!
GRC for Effective Decision Support
GRC solutions are capable of factoring in rich contextual information. Make sure that every single solution you do, data feed you take in, and scan that you incorporate satisfies information needs for at least one other stakeholder. When you identity and design accordingly you are successfully modeling your information platform. Now you’re thinking of risk models. Develop a strong relationship with your operational risk department outside of IT. They expect models for their portfolio of risks and will support your move to actually quantify and measure risk – especially for cybersecurity. The National Association for Corporate Directors (NACD) has issued guidance to pose questions that are very specific in this area and YOU NEED THE DATA! You need the data not only for the board, you need it to manage priorities on a day to day basis.
Try this: Do the “so what” test on information you gather relative to risk. Every time you ask and answer the question you are putting yourself in the next higher level of management. Do a “so what” test for every layer up that you need to inform. Now turn back to your current GRC – for every “so what” you pulled in other information to answer the question. This is information modeling. So look at the data in your GRC and ask yourself if you have pulled in:
- Your IT Portfolio of projects with their relative spends and impacts?
- Assets and classified them by impact?
- The list of vendors by tier including the spend on them (another impact hint)
- Business Continuity Planning?
… and finally, have you associated threats to your assets?
Have a Strategy
It is important to have a strategy with the stakeholders involved and a steering committee for oversight and support of that strategy. This is not a technical group, nor a venue to debate which technology should be used. This is a continued drive to answer the big questions required to grow and safeguard your organization. The focus here is key processes and the specific information needed by those processes. The underlying technology layer will be evident once you’ve established the capabilities required. Keep the executive steering committee focused on the big questions and navigating change.
Develop a strategy with a roadmap and stick to it. Once you have support and a vision, measure your progress and practice good program management of your GRC initiatives. If you don’t know the difference between project management and program management, learn it. You can evolve past the typical early heroic phases for GRC (“quick wins” and visibility struggles). You also need to develop criteria for acceptance of work like scope, context improvements for other stakeholders already in GRC, data quality and data currency. While you’re at it, don’t forget that your GRC platform is important and deserves its own risk assessment, disaster recovery planning, and capacity management planning.
Managing Your GRC Program
So how do you manage a GRC program successfully? Don’t do it alone! Work with other practitioners, and seek out communities for support. Be creative – this is a flexible platform. Be focused – this is a tool that should answer those big questions such as: Are we ready for this new market business market? What if we increased the services around this legacy platform? What is our need for cyber insurance with this new merger? If your first reaction is that you can’t answer these questions with your GRC platform, you haven’t looked under the covers at the data model. When you start with those big questions you can decompose them into smaller questions and how to get the data to answer them. If you have access to one, talk to an Information Architect – you’ll never forget how they transform data into information.
I can go on and on from experience but this is a blog. So how’s your GRC? Write me….