Despite the plethora of governance, risk and compliance (GRC) tools on the market, few approach the issue holistically. Even expensive, enterprise-oriented tools fall short
You need to construct this pilot with three important goals:
The first and most important is to uncover your functional GRC requirements. A GRC requirements document should be one of the tangible outputs of your pilot program.
Second, your pilot program should be completely functional. By definition, a pilot is a steppingstone to a larger solution -- but don't interpret this as leeway to build a subfunctional solution. It may seem difficult and counterintuitive, but your pilot should strive for full functionality at the expense of other qualities, such as scalability or usability.
Finally, your pilot program must be limited in scope. This should be obvious, but managing stakeholder expectations on such a pilot program can be difficult.
These three goals tie together. As long as you keep the stakeholders focused on the primary goal of uncovering the GRC requirements, you should be able to steer them into a consensus around a fully functional, limited-scope pilot. A good practice is to keep a backlog of your solution to capture and properly prioritize ideas. Not only will this help relieve stakeholder fears that their concerns are being ignored, but it will also help control scope by identifying multiple use cases that serve the same requirement.
Maintain the GRC connection
The relationship between governance, risk and compliance is hierarchical -- governance fits into risk, and risk fits into compliance. This relationship needs to stay connected, and employ bidirectional communication between governance and risk to ensure that your policies protect against uncertain events or risks. Your pilot program needs to prepare for any risks that could affect your governance policies.
For instance, if your policy states that all invoice payments will be in the exact amount of the originating invoice, what circumstances would compromise this situation? Your tools need to properly capture and record this risk, along with remaining risk metrics such as probability, impact and detectability.
Again, the emphasis should be on the link between the two: It's one thing to have both a good policy and risk register, but the key is how they communicate with each other.
This communication between risk and compliance ensures proper risk coverage and mitigations. We've already stated that proper risk management catalogs all the uncertain events that may upset reaching your goals. Compliance relates to the actual set of procedures to mitigate these risks. Compliance also serves another, lesser-recognized goal -- to explicitly ignore a risk for any number of reasons, including low probability, low impact or difficult detectability.
More GRC resources
Your pilot program should clearly identify what procedures will be taken for each risk. For instance, if you've identified a risk of malfeasance, your pilot should clearly identify all the procedures that will be performed to mitigate malfeasance. Your pilot program should also help you uncover the underlying risks that prompted you to seek compliance procedures to mitigate this risk. This is especially useful in cases where your organization is handed a list of procedures from a new external stakeholder, like the government. Without understanding the real risks attached to the procedures, it's hard to build a comprehensive GRC solution.
When building your pilot, above all it’s important that you take a direct approach. Build a tightly focused pilot with the goal of understanding future GRC requirements, make sure to hit the high-risk integration points, and make sure expectations are clearly communicated. Once your pilot is complete, you'll have a strong platform to move forward with either a more enterprise-scale development effort, or an enterprise-scale GRC tool. As a byproduct, you will have galvanized all the stakeholders into one common mind-set. That alone is worth a fortune.
This was first published in March 2012