Page 3

Who needs to be involved with and lead a GRC programme? 
Pike and Spencer: A key failure of organisations’ risk and compliance frameworks has been the lack of understanding of the causal relationships between different risk types. It is now understood that many risks are interrelated, and models that do not take this into account are fatally flawed. Increasingly, we see that control failures, risk events, policies, risk models and management issues are all part of a fluid network of risk that changes with the business. Each node in this network must be understood in the context of the other nodes surrounding it. GRC systems can enable managers to start mapping these relationships so they can be understood even if they cannot yet be accurately modelled. In order to do this, people who understand the various risk types and their possible relationships to others must be included in the GRC implementation project. The best person to lead a project is someone who can see across all of the functions – a chief operating officer, a chief governance officer or someone from their teams – rather than an individual from one of the assurance functions. 

Ridgway: As a minimum, the programme needs to include the heads of each of the control functions – operational risk, audit, Sarbanes-Oxley, Statement on Auditing Standards No. 70, business continuity management, technology risk and compliance. We have also found an underlying working group is necessary. Strong leadership is essential. I don’t think it matters as to the title, but you definitely need someone who is senior, experienced and passionate about the issue, and has the ability to portray a vision. The programme needs to achieve buy-in or at least acceptance that GRC is required from the chief risk officer and chief financial officer. And they shouldn’t forget to include input from key external stakeholders such as regulators.

Kapoor: Today, the GRC process is no longer an ancillary process but a core element of business operations. It touches every aspect of the organisation. While the GRC programme should be designed centrally, it should be implemented in a federated manner with active involvement of lines of businesses.

The increasing cost of managing risk, regulatory compliance and audits in silos is prompting most financial institutions to deploy a federated model of GRC that is closely aligned with business strategy and facilitates decision-making. For instance, one of MetricStream’s customers – a large bank – has successfully completed a strategic risk management initiative that aims to integrate risk management into decision-making and drive a culture of business ownership, while simultaneously ensuring compliance with industry and company standards supported by the MetricStream GRC platform.

What are the key milestones a firm needs to plan for? 
Pike and Spencer: The key milestones for such a project are defined by the main aim of the final system. One possible aim for a GRC project is to consolidate multiple assurance systems. In this context the milestones will include system installation; transfer completion from the original systems; user review of a functional match between old and new systems; full system test completion; user training; and cut-over of individual systems. Another aim is to provide integrated C-suite reporting, in which case the milestones will include all of those previously mentioned, and the definition of the reporting pack for senior executives; identification of all of the elements and calculations required for those reports; and completion of report production process testing.

Ridgway:From the project’s start, the firm needs to establish its priorities and objectives, and plan the project’s phasing. It needs to be clear on the various roles and responsibilities. Are the charters of the various control functions agreed between the teams? And what are the roles and responsibilities on the GRC project itself? You need to devise a common taxonomy – an agreed set of organisational processes, and risk and control structures that everyone is to use. Governance is important, both between the different control functions and across the GRC project.

Sponsored content