Three Starting Point upon GRC Program

 Instill GRC discipline at organizational culture, embed the GRC mechanism in the key business processes, and enforce GRC practices at daily business activities.

Organizations today encounter more risks than ever due to accelerated change, over-complex business dynamic, and hyper-competitive competition, hence, GRC (Governance, Risk Management and Compliance) program becomes a strategic imperative, but how to get it started, as the starting point is always challenging---for managing complicated a program like GRC, especially now IT governance is converging with corporate governance and Risk Management doesn't mean risk mitigation only, at a high level, it's risk intelligence.

1. Well-Define Clear Objectives 

First, you have to define what you are trying to accomplish. GRC is a meaningless term as it encompasses a lot or a little depending on the vendor's set of solutions combined with what you need. Define clear objectives [the potential is extensive and thus with huge pitfall], when defined, ensure that you have standardized/harmonized your control environment while implementing [second pitfall]. The desired outcome is to improve compliance and effectively manage risks, rather than just to report problems. 

• Start with identifying 'TO BE' processes with activities and responsibilities.
  - In those processes, identified risks by the activities, AND
  - The phase of identifying controls against those risks and also rankings.     

• Strategy as Compass: for enterprises, starting to implement GRC, you need a strategy as a compass, or EA as a framework, in order to keep on the right journey without re-inventing the wheel; governance /risk management is not just for controlling, at a high mature level, it’s risk intelligence -every risk has opportunities.  

• Get an executive agreement for a corporate risk appetite when you have your risk matrix together. Run scenarios with the exec to make sure your policies and associated controls really reflect that risk appetite. As early as possible call out your GRC service RACI, scope, limitations, and dependencies and communicate them to the exec. They need to understand how much your service can do, with current resources and funding, to improve compliance and mitigate risks. Then they need to sponsor your work to embed shared and delegated accountability throughout the business. Nothing will work without clearly understood risk and compliance accountability.  

• At a tactical level, how to embed the GRC mechanism into key processes more seamlessly, statistically, those organizations that implement GRC effectively outperform their industrial peers 20%+ in revenue growth. Define more specific goals such as: Are you trying to implement solutions for enterprise risk management, one aspect of risk management such as IT risk, compliance, internal audit, continuous monitoring, SOX, ethics programs, etc?  

2. Make Preliminary Risk Assessment 

Start with "preliminary risk assessment" to identify high-risk assets. Identify any regulatory compliance needs. Start with a risk analysis to see where you need to start your program. From there, conduct a gap analysis and start putting together policies and governance documents. Once you have identified high-risk assets and regulatory compliance needs, work on controls assessment as well as detailed risk assessment. This will result in issues/gaps that you need to mitigate. 

• Start by understanding requirements, business, and the risks (think really, really hard about the risks - spend time in slow and methodical contemplation of things unexpected, and play a lot of "what if" games), understand the policies integrated with the procedures; understand the processes you use. Analyze them to see whether they satisfy the requirements (this is a risk issue). If they don't, then modify. 

• Have knowledge of each governing policy (industry), each reflective internal policy, and each procedure. Understand how they are all tied together. This will give you some insight when defining risk areas, asset risks, and controls. Asset risk is fairly tangible, and it's the beginning of risk management. It requires an inventory of assets (many of which are IT-related, but there could be a lot that has a direct impact on the industry. Then, you can start with risk, more specifically, asset-based risk, the largest challenge, and possible where you could easily get lost in the details, identifying each asset's risks. Also, do you have any industry references as to probability, impact, or threat scoring for your assets?       
      
• Spend time early on building robust, pro-active escalation and risk acceptance processes with well-defined business approval levels. A GRC effort can live or die based on how successful exceptions and service limitations are communicated and dealt with. Make proper business cases to tolerate some compliance gaps and risks, and then inform policy reviews. Making sure policies continue to properly reflect corporate risk appetite.  

Further, no-one wants to be on the hook for an incident because they decided it was too expensive to fix something. By the same token, people forget that risk acceptance is a perfectly reasonable way to manage risk (as long as everyone signs on the dotted line to say they understood the risk and evidence of that sign off is kept). Over time that creates more credibility for the GRC function and helps when the time to fight for budget swings around.

3. Evaluate Risk Measurement & People Factor

Once identified, each has a risk measurement which can be determined and scored objectively, (a key perspective to maintain when substantiating risk). Some refer to this level as the functional risk level. It's the infrastructure, from which the operational and enterprise risk is based upon.

The Type of Risks need to be measured: The risks being measured include operational risk (processes), and that can be fairly subjective unless you've objectively identified, measured, and mitigated much of the asset risk that's involved servicing a particular process. At a minimum, it puts more emphasis on your subjective scoring process. Ultimately, your upper level of risk is Enterprise, and that is very subjective also. There's internal and external subjectivity, even speculation as you assess systemic and economic predictions. Risk management, especially GRC, as a math equation; whereas, there are a few given pieces of information which you build upon to obtain more accurate measurements, in hopes to have a solid GRC foundation, one level at a time.

Also, GRC is best managed when shared and distributed between the appropriate owners of the processes, programs, vendors, audits, and tasks. Those are really the responsible parties that are your subject matter experts. Rely upon them, and they're ownership. They'll value the program, and more likely support your efforts. You'll also have a team that will appreciate some of the burden being lifted from them.

"The soft stuff ( the human stuff) is the hard stuff": In the end, your program will become part of the culture, and not taken as such an overhead experience. It'll become the value it so rightly deserves. If you're serious about a risk-driven implementation approach for the chosen enterprise-class GRC solution, then you'll need to deal with, first and foremost, the human element. So, one of the most important Critical Success Factors (CSF's) is time-to-adoption in addition to time-to-payback.

GRC is about the entire organization, the people, processes, and technology. “Never tweaking but always redesigning." (Drucker). When it comes to motivating, build learning organizations (Senge). Plan for the fact that you have humans working at your company and humans are very creative things. They will either figure ways around your processes or will find ways to make your processes better satisfy your requirements, depending on how they are motivated. Therefore, instill GRC discipline at organizational culture, embed the GRC mechanism in the key business processes, and enforce GRC practices at daily business activities.

Posted in: GRC