By Paul de Kock
Best practice is a fluid concept, especially in the rapidly evolving Governance, Risk and Compliance (GRC) landscape. You often hear about ‘best practice’ when it comes to implementing GRC solutions. Too often, though, the idea of ‘best practice’ is driven by what suits the vendors, rather than what is in the customer’s best interests.
Best practices are those commercial or professional procedures that are accepted or prescribed as being correct or most effective. GRC is a relatively immature discipline when compared to accounting, for example. Its practices are in a state of flux, as legislation, regulations and thought leadership on the various domains of GRC change constantly and adapt to an evolving awareness of what it means to run a sustainable business.
As a case in point, there are a number of frameworks within risk assessment (COSO, ISO, COBIT etc), each of which developed independently, according to a different school of thought. Their suitability for any one organization depends on that organization’s maturity, individual requirements and attitude toward risk. Over time we are seeing the harmonization of many of these schools of thought, but many differences still remain.
Back to vendors and their approach to best practice. The previous version of our technology – developed in the early 2000s – had limited flexibility. We had no option but to encourage customers to adopt the process methodologies that we had built into the software which was in effect our best practice.
But we were swimming upstream. As we engaged with larger, more mature companies, it became apparent that each had developed – over the course of many years and much internal deliberation – their own version of best practice, one created around their organization’s specific industry, culture and accumulated wisdom.
No two organizations are alike, and a standard GRC solution is not enough. A GRC solution needs to be customizable, to suit an organization’s ingrained processes. The technology needs to allow organizations to automate their existing processes and needs to be flexible enough to change and grow with the organization.
The ISO standards inform the basic design of many GRC systems. But while solutions such as our own are typically based on the Deming cycle (Plan, Do, Check and Act, and Review), within each module there is extensive room for variation. This applies particularly to the way risks are assessed and incidents are managed and the way the myriad of GRC data is related.
To try to assert ‘best practice’ in risk assessment is problematic because there is a strong philosophical component to how risk is perceived – as the debates on many risk forums attest to. Some people believe the concept of inherent risk is flawed; how can you possibly see any risk ‘naked’, without any controls at all? Others have issues with residual risk, and how it might be calculated from assessments of the adequacy and/or effectiveness of the controls that have been instituted. Each large organization has typically adopted their own interpretation of what risk means to their business.
Similarly, incident or event management processes are usually unique, and based on the nature of the business and the type of event being managed. Aspects such as which type of investigation methodology is preferred (root cause, Taproot, fishbone, five why’s, ICAM etc or, which is usually the case, a combination of two or more of these depending on incident type and severity), how insurance claims are managed, and how return to work is handled after an injury are highly business-specific. Within diversified groups, processes for incident management might differ significantly internally, as business units or subsidiaries might have substantially different requirements. The trend towards integrated GRC, with a single Event management function replacing multiple functions for non-conformances, incidents, non-compliance and loss events, also makes defining an overarching ‘best practice’ extremely difficult.
It was pressure from our larger customers that made us realize that we had to improve our software to become hyper-agile and able to accommodate whatever processes they threw at us. There are undoubtedly huge benefits to be derived by implementing template ‘best practice’ solutions for customers who are less mature and need guidance as to how best to roll out their GRC practices. But for more mature customers this approach can be a limiting factor. The approach our company has settled on is to offer solution templates, which are in effect best-practice starting points, which might provide a 65% or 95% fit, depending on a customer’s maturity and how established and effective their existing processes are.
Change management is always one of the most difficult aspects of IT solution implementations, and a strong benefit of not forcing customers to conform to a pre-set best practice, but rather tailoring the solution to their processes, is that users adopt the new software more readily as it closely aligns to what they were doing before, albeit using spreadsheets, paper forms or disparate point solutions.
It was a critical juncture in our company’s history, the day we committed to developing our software into a hyper-agile GRC framework that could give our larger customers what they want, the way they want it at a cost and implementation timeframe that is similar to an off the shelf product implementation. We can now give them their best practice, and we know that that is what they actually require. Hyper-agility allows our GRC solution templates to continually evolve as the disciplines within GRC evolve which means we have also not walked away from our less mature customers who are happy to be guided by our version of “best practice”.