The CMMI or Capability Maturity Model is an established, generally applied framework for business process management. CMMI has been successfully used to help map meaningful strategies and align objectives in many business circumstances and industries over the years.
The time is ripe to apply this framework to GRC Technology implementation. The model itself is highly flexible and easily conveyed in most organizations. This is significant, given the fact that GRC, as a term, is now often used to represent a specific layer of governence, risk and compliance management in the context of one group of responsibilities, users or technologies. This manipulated use of the GRC concept causes unnecessary confusion between the context of a process in a sub-set of GRC (such as information security) and its connection to the primary objectives of GRC across the organization served by all processes.
Evidence of the opportunity to develop a clear set of guidelines for GRC Technology Maturity comes from the ISM3 (Information Security Management maturity Model). This framework maps the InfoSec maturation process in an applicable format for organizations as they face increasing information complexity and growth in IT systems and applications over time. With such models in hand, OCEG is beginning to develop the first version of CMMI for GRC Technology implementation. The current OCEG Capability Model for GRC process management provides a strong and consistent set of guidleines for the development of an aligned GRC Technology CMM.
L. Leskela
Friday, July 25, 2008
Subscribe to:
Post Comments (Atom)
5 comments:
Here are some elements of organizational GRC maturity along Four stages of the CMM:
Stage 1: Initial-Reactive
1) A low overall level of
understanding of GRC
Requirements throughout
The organization
2) No established GRC
Management Processes
Exist
3) Tools for ad hoc and
one-off risk or compliance
Processes exist in
isolation
4) Responsible staff adopt
applications and
techniques as needed
for specific tasks
5) GRC itself is not visible
In the Objectives for the
Organization or for
senior management
Stage 2: Managed-Projects
1) Department-specific
understanding of limited
GRC requirements exists
2) Ad hoc processes have
been developed for
isolated requirements in
specific departments
3) Siloed GRC projects
have emerged and require
specialists to perform
4) GRC efforts are
all running in parallel
And tasks are inevitably
duplicated
5) Specific mandates and
Immediate risks are treated
as individual, one-off
projects
Stage 3: Defined-Proactive
1) A managed GRC program
or full PMO for GRC is now
In place
2) Multiple GRC projects
are being coordinated
In some closely-related areas
3) Process and reporting
exceptions, gap analysis
and remediation processes
are underway
4) Standardized process
definitions, metrics and
outcome measures
have been applied to high
priorities
5) Some information
technology and specific
applications are used to help
manage risks, processes,
analysis and reporting
Stage 4: Measured-Controlled
1) The GRC PMO integrates
the fulfillment of existing
and new GRC requirements
2) The organization
measures, evaluates and
Identifies the value derived
from GRC process
automation
3) The most common GRC
Processes are automated
And relevant tools are
integrated
4) GRC responsibilities are
Federated and managed
From centralized corporate
Roles and policy
5) Long-term obligations,
Enterprise risks and
Corporate objectives are
generally coordinated
Lane, based upon the characteristics of level 4, it describes the environment I had in place as a CCO working on this 6-7 years ago. It is a great measurement and a great place for a company to be. However, it doesn’t cover the scope and various domains but does more to describe the high-level organization properties. I think we need to address scope as we describe maturity levels.
For example, you may have a Privacy program with federated management, change control and oversight but not be involved at all with product regulatory compliance, financial risk management, security, AML, records retention, etc.
Scope of maturity level properties or characteristics should be added for each level in my opinion. The PMO for GRC is just one aspect of developing and integrating new and changing requirements into the overall GRC environment. The measurement, monitoring, compliance audits and various types of stakeholder reporting could be done by the GRC PMO but they tend to have their hands full managing project like initiatives being integrated into the broader GRC environment which would be better served functions for the central or corporate compliance office of which the GRC PMO would be a part.
Just my thoughts.
Post a Comment