Category: The GRC Pundit Blog

New GRC strategies, mergers, acquisitions . . . the last few weeks have been hopping for a market research analyst.Every time I sat down to blog on my thoughts someone else has come out without an announcement resulting in a whirlwind of buyer, market, and press questions.Between sessions at the OCEG GRC 360 Executive Forum I have found time to gather my thoughts and provide them to you briefly.

However, this is just a pause in the storm of GRC related activity happening.There are a few other announcements I expect to hit the press in the next month or two as other GRC vendors revise their approach as well as focus on more consolidation through acquisitions.

For now – let us look at the announcements by IBM/OpenPages, Wolters Kluwer/FRS Global, and Thomson Reuters – in the order they were made public.

IBM to Acquire OpenPages

IBM has struggled for years with a consistent technology approach to GRC.While I have found that IBM Global Services has fairly consistently delivered a GRC related vision for services, IBM has struggled on the technology side.Five years a go IBM was really pushing Workplace for Business Controls and Reporting as their GRC platform.This did not received by the market very well and IBM thus let a GRC strategy drift in different areas of the organization.IBM acquired FileNet in 2006 – FileNet was starting to make some very focused traction in GRC before the acquisition but fell off the GRC radar after the acquisition.Overall, GRC was hijacked by IBM Tivoli and largely took on an IT risk and compliance view and was not truly enterprise GRC.

OpenPages has been one of the primary market leaders in GRC technology for several years.In the number of GRC related projects Corporate Integrity gets involved with, OpenPages is in the top three vendors (along with Archer and BWise) to consistently get into the final selection in GRC RFP/RFIs.OpenPages has had particular success in focusing on the financial control as well as operational risk management aspects of GRC.

My two cents . . . the acquisition of OpenPages by IBM could be good or bad.It validates the market growth and interest for GRC and is spurning a lot of other activity by other large solution providers looking at GRC.However, I was disappointed that the IBM announcement itself did not reference GRC.It focused on risk management with some limited discussion on compliance – but did not reference the concept of GRC to provide efficiency, effectiveness, and agility to harmonize GRC processes across the business.There seems to be particular interest in enhancing the relationship between business intelligence/strategy (the Cognos side of IBM) with OpenPages risk management capabilities – this is highly interesting and relevant.However, there is a chance that OpenPages itself gets lost in the aftermath of an acquisition and loses market momentum.My advice to IBM is to clearly define and articulate a GRC message and strategy and maintain the OpenPages brand and market momentum.Further, OpenPages has tried with limited success to penetrate the IT Risk and Compliance market – IBM should make OpenPages the process and content hub for an IT GRC strategy that connects with the wide array of IBM’s security and IT management technologies.

Wolters Kluwer Financial Services Acquires FRS Global

In the GRC market – content is king.Many of the vendors have great technologies to manage risk and compliance processes, establish accountability, and implement workflows.The major area lacking in many platforms is content.In the world of IT risk and compliance there is a lot of content for control libraries (e.g., Unified Compliance Framework) but most GRC platforms do not have much to offer when it comes to domain/industry content for risk and compliance.Several major content providers such as SAI Global, Thomson Reuters, and Wolters Kluwer have been acquiring a range of GRC technology providers and integrating their content with them (Lexis Nexis has worked more on OEM/partner strategies in the GRC space as with their partnership with QUMAS).

Wolters Kluwer has articulated a very specific GRC strategy in their ARC Logics brand that branches across the range of their GRC technologies they have acquired (e.g., Axentis, Ci3 Sword, MediRegs, TeamMate).Part of their strategy is to focus broadly across industry as well as have deep industry focus on specific industries.Financial services is a specific industry of focus (as well as healthcare and others).The acquisition of FRS Global is a very positive execution on their strategy to integrate content and technology and deliver value to financial services organizations specifically.FRS Global will extend the impressive risk capabilities found in the ARC Logics Sword product to deliver regulatory reporting for financial services as well as enhance risk management capabilities. Combined with the breadth of Wolters Kluwer financial services content – this acquisition will further enhance Wolters Kluwer ability to deliver GRC value to financial services organizations.

Thomson Reuters Launches Governance, Risk, and Compliance Business Unit

It is about time.Thomson Reuters was one of the first companies to articulate an integrated GRC technology and content strategy.However, this was locked inside the Thomson Reuters Tax and Accounting business unit and failed to branch out into other areas of Thomson Reuters.During this time Thomson Reuters has acquired other technologies and content providers (e.g., Complinet).When you look at the vast content resources that Thomson Reuters delivers, they could be the leader for GRC if they can successfully and integrate content and technology.

I have had some concerns if they could successfully maintain technology.The Tax and Accounting business unit was focused on deep content needs and technology always appeared as a band-aid in the GRC deals I have seen them involved in.I have not seen the investment and advancement of the Paisley product they acquired a few years back.

This new business unit is just what is needed.Thomson Reuters has articulated a beautiful vision of technology and content integration, which combines their GRC technology platforms into a single business unit and articulates integration with WestLaw and other Thompson Reuters leading GRC content.My gut feel is that this focus on a GRC business unit will allow broader implementation of GRC content into technology but also allow the technology itself to be a priority of investment and development.This should not only keep Thomson Reuters competitive in the market but allow them to be a primary leader in it if they can execute on this vision.

 Why GRC & What Is It?

GRC, simply put, is to provide collaboration between silos of governance, risk, and compliance. It is to get different business roles to share information and work in harmony. Harmony is a good metaphor, we do not want discord where the different parts of the organization are going down different roads and not working together. We also do not want everyone singing the melody as different roles (such as risk, audit, compliance) have their different and unique purposes.

Note: GRC is not a restructuring of the organization. It is getting varying risk and compliance roles to cooperate, collaborate, and share so there is a big picture of risk and compliance to oversee that the organization is properly governed.

When it comes down to it . . . the acronym is not important, there are many GRC initiatives that I get involved with that do not use the term GRC. The goal is the same – to drive efficiency, effectiveness, and agility across risk and compliance processes to support a dynamic and extended business environment. GRC is a lot about process improvement and sharing information and processes. It is about simplification and efficiency.

Compliance should not drive risk. Nor should risk drive compliance. They both should cooperate with each other and share relevant information. Compliance is being challenged to do periodic risk assessments for unethical/non-compliant/criminal behavior. Audit is being challenged to do risk-based audits. Should these roles completely reinvent risk and risk management or work with the risk management team within an organization cooperatively, to learn from the risk experts themselves, to use a framework like ISO 31000 which is aligned to the OCEG GRC Capability Model?

On the flip side, risk needs to work with compliance. The current economic mess is due in part to many banks that had good credit risk policies – they knew their thresholds and appetite, and it was articulated in policy. The issue was they were not compliant with there policies. Risk management without a compliance program is ineffective. Again – two different departments with their own expertise that need to work together.

I think we all know the answer to that. Cooperation is best. To let different areas of the business lead where they excel but not dominate the others. But to work together in harmony – to collaborate and share information and processes so we can achieve a holistic view of risk and compliance across the business.

While the GRC term is 8 years old, I state in my research and teaching that it is nothing new. Organizations have been doing GRC all along. The issue is have they been doing it efficiently (human and financial), effectively (meeting internal and external requirements), and with the proper agility (for a dynamic and extended business environment)? Does the approach we have been taking make sense or are there better ways to do things that bring more process efficiency?

That is what GRC is about – that is the philosophy behind it.

As for the formal definition of GRC. . .

From OCEG’s GRC Capability Model: GRC is a system of people, processes, and technology that enables an organization to:

Understand and prioritize stakeholder expectations.

Set business objectives that are congruent with values and risks.

Achieve objectives while optimizing risk profile, and protecting value.

Operate within legal, contractual, internal, social, and ethical boundaries.

Provide relevant, reliable, and timely information to appropriate stakeholders.

Enable the measurement of the performance and effectiveness of the system.

As my friend and colleague Norman Marks states, “The definition can perhaps best be summarized as how an organization understands stakeholder expectations and then directs and manages activities to maximize performance against those expectations, while managing risks and complying with applicable laws, regulations and obligations.”I have some IMPORTANT NEWS to announce. The OCEG GRC Certification test is ready to be released.

 

GRC Certification & Training

To date there has not been a GRC certification for individuals that is based on a publicly vetted common body of knowledge. The only source of such knowledge, in my experience, has been OCEG’s GRC Capability Model.

 

Now OCEG is releasing a GRC certification for individuals based on the very popular GRC Capability Model.

This is a landmark certification. There is not other GRC certification based on an open and vetted source of GRC guidance that is a compendium (I call it the GRC Rosetta Stone) of guidance from across over 100 standards, frameworks, best practices, and regulatory guidance. This is the GRC Capability Model found in the OCEG Red Book. It defines a process model of common elements, principles, sources of failure, and other areas for a successful GRC strategy or individual risk and compliance effort.

OCEG has confirmed that those that attend the next two GRC Bootcamps (London in October and Dallas in November) will have an opportunity to take the written test during the bootcamp with no additional fee for testing – only for these two bootcamps. However, the individual registering for the bootcamp and to take the test must be an OCEG Individual Premium member or higher. I highly recommend that you consider attending one of the next two GRC Bootcamps so you can be among the first to receive this certification. After these two Bootcamps there will be an additional fee for the test/certification.

 

I am a man on a mission. Make that a business on a mission – to completely refocus organizations on how they approach policy management and communication. To take business to the new frontier, to boldly go . . . You get the picture.

Policies are in a complete and disappointing disarray. In my training and workshops I have found bright spots. There are organizations that are developing a consistent enterprise-wide approach to writing, communicating, and managing policies and procedures across the organization – supported by a centralized system to manage the policy life-cycle.

However, most organizations are a mess:

• Policies are scattered, written in varying language styles with inconsistent use of definitions and terms.
• Often out of date (I have seen policies of organizations that have not been reviewed in a decade).
• To make matters worse – they are often scattered across different internal websites and document systems.

What are organizations thinking?

Policies define and articulate the corporate culture. They set expectations and boundaries for what is acceptable and unacceptable. They also can establish a legal duty of care for the organization.

Enough of that – I have written plenty on this issue. Today I want to bring it to a new level. Not only are businesses failing in consistent and effective policy management, they are also behind the times in communication.

To the point: How do you manage and communicate policies in a YouTube generation?

In my training and advisory I am encountering organization after organization stating that the new generation of workers are demanding video. They do not read policies. Do not get me wrong – the written policy will always be critical as it defines what is allowed and disallowed to the ‘letter’ and is critical. The issue is how do we communicate to a generation of workers what expectations and boundaries are when they have been raised on video?

The answer is we need to take policy management systems to a new level:

1. Any employee (across geographies, educational levels, and disabilities) should be able to log into a centralized policy platform and be able to find all of the policies and procedures that relate to their role in the organization.
2. These policies should be written clearly in a consistent template and style that reflects the culture and tone of the organization.
3. These policies are to be written in a way that the average reader can understand.
4. Any tasks for the acceptance and attestation to policies should be clearly communicated and easily accomplished.
5. It should be apparent how to ask for help and clarification on the policy by having a phone number or link to ask questions.
6. Finally, and to the point, many policies (but not necessarily all) should have a video component in which the policy is explained to the individual.

This video component should be integrated into the policy management system – not just a link to some other systems. I firmly believe the value and ease of use is realized when the written policy and the video training on the policy are in the same integrated interface.

This is what I call Next Generation Policy and Procedure Management.

What are your thoughts and experiences on managing policies and procedures?

Corporate Integrity is also delivering a full-day workshop on this topic:

Chicago, IL, USA – Effective Policy Management & Communication

Date: August 23, 2010 – 8:00 AM to 5:00 PM (PT)

I would love to hear your thoughts on the topic of Policy Communication in a YouTube Generation. Please feel free to comment or send me an e-mail.

Sincerely,

Michael Rasmussen, J.D., CCEP, OCEG Fellow
Risk & Compliance Lecturer, Writer, & Advisor
[email protected]

 

Businesses are engaged in a continuous struggle to grasp the intricacies of risk management in an interconnected environment. The focus during the past few years has been on operational risk management — managing risk to business operations and processes. However, the standard definition used for operational risk management is flawed:

Operational Risk Management: “. . . the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events.”

What is wrong with this definition? It completely ignores the impact of extended business relationships on operations. Properly revised, it would read “the risk of loss resulting from inadequate or failed internal processes, people, systems, and business relationships, or from external events.”

No organization is an island unto itself. Risk and compliance challenges do not stop at the traditional organizational boundaries. Organization area complex and diverse system of processes and business relationships that cross countries or span the globe. Organizations struggle to identify, manage, and control governance, risk management, and corporate compliance (GRC) across extended business relationships. Adding to this is the growth and focus on corporate social responsibility (CSR) initiatives that force organizations to determine if business partners hold the same values, practices, and ethics communicated to stakeholders, customers, and the world.

The bottom line: Organizations are complex entities that extend to hundreds or thousands of business relationships around the world. Even the smallest organization can have diverse global business relationships. The impact of the extended enterprise is significant for business. Organizations must actively manage and monitor risk and compliance across the lifecycle of a business relationship.

Any given organization stands in the shoes of its vendors and delegated partners/entities – their problems are your problems and their issues can directly impact your brand and reputation. The challenge before organizations is “Can you attest to an in-compliance status of your extended business relationships across the range of risk issues that can impact your business operations and brand?” . . .

This posting has been an excerpt of Corporate Integrity’s published research, Managing Risk & Compliance Across the Extended Enterprise.

Corporate Integrity is also delivering a full-day workshop on this topic:

Chicago, IL, USA – Managing Compliance Risk Across Extended Business Relationships

I would love to hear your thoughts on the topic of Managing Risk & Compliance Across Extended Business Relationships. Please feel free to comment in this forum, or send me an e-mail.

There has been a lot of consolidation and restructuring in the GRC space already in 2010 – SAI Global takes the next step by acquiring Integrity Interactive.

As an industry pundit and analyst it is always fun to play match maker. For some time I have been pontificating that SAP and CA are very complimentary in their approach to the GRC market. While one focuses on business processes and applications (SAP), the other (CA) focuses on IT management and security. I was quite excited when they formally announced that they have worked out a partnership and demonstrated an interesting level of integration.

Business today requires agility and efficiency to stay competitive. Organizations must respond rapidly to changing conditions, while managing financial and human capital costs.

Compliance processes often work against business agility and efficiency. Requirements and initiatives bear down on the business, and become burdensome and inflexible. When managed manually and/or across numerous siloed business units, compliance can slow down and encumber the business.

Risk can be a burden or a tool that enhances business performance. Healthy risk-taking drives business; however, organizations must understand whether they are taking the right risk, if risk is being managed effectively, and how to monitor risk. A cavalier and uncontrolled approach to risk will result in disaster — even for companies with strong brands.

Poorly managed risk and compliance generates complexity, redundancy, and failure. In this instance, the organization is not thinking about how controls and processes can be architected to meet a range of risk and compliance needs — nor does it gain an understanding of how risk management and compliance impact corporate performance. Too often organizations are reactive and lack a cohesive strategy. This isolated and periodic snap-shot approach to risk and compliance causes organizations to spend excessively on internal management and external auditors.

What may seem like an insignificant risk in one part of the organization may have a different impact when other risks are factored-in, either from another business process or risk category. Organizations are at-risk when they rely upon out-of-sync controls and disconnected corporate policies. Executives are becoming aware of these redundant risk-and-compliance projects, and are identifying the need for an integrated governance, risk, and compliance (GRC) strategy.

Organizations report significant issues and cost associated with manual and basic technology approaches in these areas:

• Common anomalies, malicious activity, and errors go undetected.
• Significant spend on external auditors and consultants.
• Horrendous reporting.
• Unmanageable amounts of paper and spreadsheets.
• Reactive after-the-issue fire fighting.

Success in today’s dynamic environment requires organizations to integrate, build, and support business processes with an enterprise view of GRC. While new risk and compliance issues constantly come to bear, organizations must take care to tackle the problem at its roots. A sustainable enterprise view of GRC means accountability is effectively managed and a complete system of record provides visibility across the key business processes and multiple applications.

Technology should empower business-process owners (who are also the control owners) to manage risk and compliance continuously. Technology can directly integrate controls within business processes, applications, and systems to prevent and/or detect unwanted behavior. IT should not be required to operate the control environment, which will improve the security of the audit trail. Audit does not need to be a quarterly event, but part of everyday activity and good business practices. This leads to cost savings and efficiency, while allowing the organization to remain agile.

A well-designed system of control is not necessarily a well-operating system of control. Many organizations pursue GRC with limited results as they have focused their efforts on GRC documentation. While this concept and approach to GRC is a good start, achieving efficiency in GRC requires a GRC strategy to be operating effectively not just designed (documented). Operating effectiveness is where GRC value is obtained and is built upon design effectiveness:

• Design effectiveness: Begins with understanding of how a GRC system of internal control is effectively designed. To determine this, the organization starts by documenting controls and processes. An assessment is performed, and for each risk and compliance requirement, controls and incentives that mitigate risk are identified. Ultimately, the organization must determine whether these controls and incentives and the system as a whole are designed to satisfy stakeholders and regulators while managing risk and requirements.

• Operating effectiveness: An effectively operating GRC system considers how GRC is being managed within business, and its impact on the business. The organization should determine if the system operates as-designed, and if the system supports the needs of a dynamic business in a way that increases business agility while minimizing use of financial and human capital resources.

Organizations face a complex array of risk and compliance demands that impact the business. The organization must implement control-monitoring processes and technology that streamlines GRC operations, minimizes risk, meets regulatory requirements, and supports business agility and efficiency. GRC control monitoring should exist within the context of business processes and the supporting application environments, and across all potential sources of change to those controls.

Achieving efficiency and value in GRC requires a long-term GRC vision, and shorter-term wins. The more extended and distributed the business is, the more challenging risk and compliance are to manage. A solid GRC foundation provides an extensible technology platform that is adaptable and scalable. An enterprise GRC solution does not operate as a silo unto itself, but integrates with critical business processes and applications. The goal is to:

• Avoid issues and mitigate risk: Organizations must mitigate loss, fraud, error, and risk within acceptable boundaries. GRC automation allows the organization to detect potential or actual issues within key business processes and applications, to avoid negative or unintentional consequences.

• Reduce reporting time: Effective operation of GRC means creating efficiency in human and financial capital resources. It is critical to implement a GRC approach that reduces the amount of time spent by internal and external assurance personnel.

GRC is about protecting the business — staying within defined risk and requirement boundaries to minimize loss while optimizing performance. An organization approaching GRC proceeds through three levels of maturity:

1. Manual and isolated: The first level is a reactive approach to risk and compliance. Different issues are managed in different parts of the organization, relying on burdensome and costly approaches to managing risk and compliance. This ad hoc approach is a manual and labor-intensive process, and results in mountains of paper and electronic documents. This produces a compliance posture that is often full of holes or outright smoke-and-mirrors.
2. Documentation and workflow: The second level is documentation of GRC controls and processes. This is often maintained in document or policy-management systems that have content and workflow capabilities, but little understanding of business processes and no integration with the underlying business application environment. The focus of this level of maturity is the design effectiveness of GRC — to document the busin
   ess appropriately to satisfy regulators and stakeholders.

3. Control automation and monitoring: The third level focuses on the operating effectiveness of GRC. Here, the organization achieves economies in GRC through processes and controls connected and in-sync with objectives, policies, and risks associated with business processes and applications. Value is created by ensuring that control violations are identified immediately, minimizing loss from fraud and errors, and by greater efficiency in human and financial resources.

The most economical GRC approach focuses on automation and efficiency. The goal is to connect policies and procedures to control objectives and automate monitoring and enforcement of controls. Automated controls can span business processes, applications, and information to reduce inefficiencies in current methods of internal control monitoring and validation.

The importance of automated monitoring increases as the velocity of change steps up within the organization. Change can be good or bad. As companies expand the number of users spread across geographies, there is more opportunity for mistakes, fraud, or operational errors. Growth also multiplies the application levels within which users can make changes, for both end-users and database users. Changes can also come from third-party systems running batch processes, application triggers that are poorly implemented, or stored procedures that do not leave a transaction footprint. Accidental changes can occur during IT system upgrades, patches, or restarts.

When control monitoring becomes a background process of everyday business activities, a continuous real-time audit trail is always available. This eliminates the need for time-consuming investigations that take place when exceptions are identified, weeks or months after the fact. The scope of monitoring can expand beyond a limited subset of key controls required for compliance activities. By empowering business process owners to monitor the integrity of their operations, operational risk from fraud and errors is greatly reduced.

For audit and compliance, this eliminates or greatly reduces sample-based audits while providing a comprehensive control baseline and change history for data and processes. The scope of review can also be significantly expanded without requiring additional resources: Audit processes that were performed once every several years can be done continuously. Once validated, auditors can rely on the existence of automated controls and continuous change-tracking as evidence of compliance.

This posting has been an excerpt of Corporate Integrity’s published research, Achieve GRC Value – Efficient Business Process & Application Monitoring.

I would love to hear your thoughts on the topic of GRC Software. Please feel free to comment in this forum, or send me an email. Please comment on this blog or send me an e-mail.

While GRC is ultimately about collaboration and communication between business roles and processes, technology provides the backbone that enables GRC. To describe this technology, Corproate Integrity has defined the GRC Reference Architecture (this is closely aligned to the second version of the Open Compliance & Ethics Group (OCEG) GRC Technology Blueprint).

This model is meant to be a practical and applicable tool for organizations trying to understand and implement technology for GRC.

GRC today is akin to customer/client relationship management (CRM) in the 1980s. Before CRM systems and processes entered the organization, client information and relationships were being managed. The challenge was that there were scattered silos that created inconsistent and redundant data, with no view into the entire profile of the client and its interaction with the business. CRM systems create a single view of customer information and interaction across business processes and roles. GRC systems and processes aim to achieve the same thing — to provide an integrated picture of governance, risk, and compliance information and processes across the business. This requires an integrated view of GRC business process and technology architecture.

A high-level view of the GRC Reference Architecture comprises the following areas:

• Information architecture: Conceptualizes the interrelationship of GRC-related information that bring agility, efficiency, and effectiveness to the entire organization.
• Enterprise GRC applications: Represents solution areas that span risk and compliance roles and processes. These solutions are not locked to a single business role, function, and process, but are leveraged among all of them.
• GRC role and process-specific applications: Describes GRC-role specific applications. These are solutions designed for a specific business role or function to accomplish a specific set of tasks. These applications are typically used predominantly by one area of the organization.

A firm GRC foundation is built upon solid information architecture. The burden, inefficiency, and ineffectiveness — as opposed to agility, efficiency, and effectiveness — of risk and compliance processes results from a lack of integrated and interrelated information architecture.

An intricate relationship of information from across the organization is the heart of a successful GRC technology strategy. All policies, risks, controls, events, requirements, enterprise assets and processes, responsibilities, and objectives interrelate and support each other. When managed in information silos, each of these areas bring inefficiency to the risk and compliance processes.

For example, organizations must understand which policies set management thresholds for specific risks; which events violate specific policies, materialize risk, and cause infractions of regulatory requirements; which controls are established for specific policies and are defined to control certain risks; and which business objectives involve risk, and how their controls allow pursuit of the objective but stay within acceptable risk-tolerance levels.

Enterprise GRC applications interact, share, and leverage the information model to deliver sustainable, consistent, efficient, transparent, and accountable GRC processes. This requires the application to be used across the business as a platform that touches and interacts with a variety of business roles and information. These foundational applications must deliver on the GRC philosophy of a common architecture and collaboration across business roles and interests.

Dozens of application categories fall outside the enterprise GRC application core — these applications focus on specific business roles and functions, such as quality, environmental, health, and safety (EH&S ), and matter management. The enterprise GRC application core consists of the following applications:

• Audit and assurance management: Audit and assurance management systems manage audit cycles and output — this includes audit resource scheduling and calendaring, audit work paper management, and audit process management.
• Case and investigations management: Case and investigations management software is used to manage investigations, issues, incidents, events, or cases. It specifically provides consistent documentation and management of events — from reporting to managing and documenting the investigation, to recording the loss and business impact.
• Compliance management: Corporate compliance systems support the overall coordination of legal, regulatory, contractual, and corporate policy requirements and responsibilities with associated tasks and records of adherence.
• Control activity and monitoring: Control management and monitoring systems provide the ability to define, record, map, monitor, change, alert and report on information processing (financial and operational data). This includes the limitations or conditions applied to amounts and parties in a transaction; user access, rights, and responsibilities; and accounts, workflows, and process initiation.
• Hotline/helpline: Employee hotline and helpline systems are confidential, independent information intake and response systems for reporting potential internal fraud, negligence or impropriety by co-workers, partners or contractors. Employees can also use them to seek clarification on policies, and procedures.
• Policy and procedure management: Policy and procedure management systems help develop, record, organize, modify, maintain, communicate, and administer organizational policies and procedures in response to new or changing requirements or principles, and correlate them to one another.
• Risk & Regulatory intelligence and monitoring: Regulatory intelligence and monitoring systems monitor external and internal changes, and alert the organization to regulatory and legal conditions that can impact their business. Risk intelligence and monitoring systems monitor external and internal changes, and alert the organization to risk conditions (e.g., geo-political, economic, natural disaster) that can impact their business.
• Risk management: ERM systems mange implementation of frameworks and processes that apply parameters, indicators, measures, consequential outcomes and business scenarios related to financial and non-financial risks. Operational risk management systems and applications implement and monitor risk processes that define parameters, indicators, consequential analysis and “what-if?” scenarios that stem from performing tasks and from passive activities. Risk analytics and modeling systems help identify specific causes of risk, given the potential consequences of events and the likelihood of events occurring sequentially or simultaneously. These tools execute historical reviews, simulations, interpretations and project impacts to operations, assets, or individuals.
• Strategy, performance, and business intelligence: BI, strategy, and performance systems examine the systems, processes and applications that manage collection, integration, analysis, and presentation of all layers of planning, strategy, performance, operational, procedural, and decision-making information.
• Training a
  nd awareness: Training and awareness systems manage the learning and understanding of compliance, policy, and risk areas to employees and extended business relationships. They combine training content with learning management system capabilities.

The enterprise GRC application core provides the foundation of GRC across the business. All of these applications can be leveraged from one side of the business to the other, to provide a consistent approach to GRC across silos of risk and compliance. However, a variety of business functions and roles have specific needs that demand applications aimed at their business function. These applications plug into the broader GRC Reference Architecture.

GRC is a federated effort. There is no such thing as one group of the organization that “does” GRC. While there may be a role in leading the collaboration, GRC must extend throughout the business. Business role and function-specific applications predominantly focus on the needs of a specific business function, process, or role in the enterprise. Applications in this area may have significant risk and compliance relevance and impact on the enterprise — but 80% (or more) are used by a specific user or role subset. The enterprise application core represents applications that span GRC business users and roles across the business.

The business roles and functions with specific need for GRC technologies and applications are scattered across the enterprise. In one sense, every part of the business touches on GRC as it relates to different aspects of performance, risk, compliance, values, and control. Primary, not all-inclusive, business function/role application categories include:

• 3rd/vendor/supply-chain risk and compliance
• Board and entity management
• Brand and reputation management
• Business continuity management
• Contract management
• Corporate social responsibility
• Discovery/e-discovery management
• Environmental monitoring and reporting
• Environmental, health, and safety
• Fraud detection and prevention
• Global trade compliance/international dealings
• Information/IT risk and compliance
• Insurance and claims management
• Intellectual property management
• Loss management
• Matter management
• Physical security management
• Privacy
• Quality management and monitoring
• Risk management – finance and treasury

These roles represent a significant but not exhaustive look at the categories of risk and compliance software solutions targeted at specific areas of the business. The applications must be able to report and feed information into broader GRC reporting systems and dashboards to maintain a 360-degree view of GRC. All are very relevant, and part of a broad GRC strategy.

The GRC Reference Architecture is a model of the technology landscape of GRC solutions. Currently there are more than 400 different technology providers delivering solutions for narrow to broad aspects of governance, risk, and compliance. The GRC Reference Architecture is part of Corporate Integrity’s broader GRC EcoSystem, which catalogs more than 1,300 technologies, professional service firms, and information/content providers. This posting has been just an excerpt of Corporate Integrity’s published research, GRC Reference Architecture: Understanding the GRC Technology Landscape.

I would love to hear your thoughts on the topic of GRC Software. Please feel free to comment in this forum, or send me an email. Please comment on this blog or send me an e-mail.

ONLINE WORKSHOP: The GRC Reference Architecture

Understanding & Approaching GRC Technology for Your Business

GRC – Governance, Risk, & Compliance. Whether you use this specific acronym or not the fact is your organization does GRC. There is not a single executive that will tell you that they lack corporate governance, do not manage risk, and completely ignore compliance. The truth of the matter: GRC has been a part of business since the dawn of business. In this 2 hour online workshop, Corporate Integrity defines and communicates The GRC Reference Architecture. This GRC Reference Architecture is part of my broader GRC EcoSystem of technology, consultants, and information providers (over 1300 firms cataloged to date). And is synchronized to the OCEG GRC IT Blueprint

The GRC Reference Architecture is comprised of: information framework, enterprise core GRC application(s), role/business function specific applications, as well as industry and geographic/jurisdiction specific applications.

The goal is to assist organizations in understanding the breadth of the GRC technology landscape, how different GRC technologies can and should work together, and provide the foundation for developing a GRC technology plan to support your organization’s risk and compliance process requirements.

ONLINE WORKSHOP – The GRC Reference Architecture

Date: Thursday, July 01, 2010 from 11:00 AM – 1:00 PM (CT)

I am amazed at the number of risk management programs I encounter that lack an organized structure and approach. So often what we know as ERM (enterprise risk management) is a hodge-podge of processes and assessments that somebody tagged the ERM label on without much thought for what they were doing. In fact, most of the ERM processes I encounter are nothing more than a slightly expanded view of SOX and financial controls: they are not truly an enterprise view of risk across the organization and its operations.

Most ERM programs lack the fundamental building blocks for a risk management program. This begins with a well written charter for ERM and a supporting ERM policy.

A recent client of mine, looking to engage me in the development of an ERM policy, asked what the main components of an ERM policy are.

MY ANSWER: ERM policies are organization specific; no two ERM policies are identical. However, there is a logical structure that works well as a starting block for most organizations. These include the following structural components for an ERM policy (note: these same components can be used for other risk management policies besides ERM such as IT/information risk management):

• Objective/Purpose. As with any policy it is necessary that the policy begin with the organization and purpose of the policy. This is nothing more than writing out the charter for ERM and establishing the authority of this policy to establish and govern the ERM program.

• Risk Governance Structure. It is critical that the organization establish the governance structure for risk management. This is a big area of failure for most ERM programs when it is often the case that risk management operates as an island with very little to know interaction with the board and executives. A solid ERM policy will identify how the board and its committees interact with ERM as well as senior executives.

• Roles & Responsibilities. Once the governance structure is in place, the policy should get into specific roles and responsibilities for ERM. This includes a clear understanding of the roles of a Chief Risk Officer, executive management, business operations, risk management staff, and the role of audit in the assurance oversight of risk management.

• Risk Culture. The single greatest hurdle to successful ERM is articulating and integrating risk management into the organization’s culture. In one sense risk management is part of the culture no matter what is articulated in policy – an organization can have a cavalier approach to risk taking, a structured approach to risk taking and oversight thereof, or anywhere in between. The organization needs to clearly spell out how the organization approaches risk taking, management, and ongoing monitoring of risk in the organization.

• Risk Strategy. Following on the heels of risk culture, the ERM policy should next deal with how ERM aligns and integrates with corporate performance, objective, and strategy management. ERM often is disconnected from these areas which makes it of little practical use to the organization.

• Risk Tolerance & Appetite. The next logical sequence in the ERM policy is to establish the boundaries of risk taking in articulating the organization’s approach and boundaries to risk tolerance and appetite. It is hear that the policy discusses what is acceptable and unacceptable risk. This provides the high-level boundaries and approach to risk taking, though most of the specifics on these boundaries will be found in supporting policies (e.g., credit risk policy).

• Risk Taxonomy. The ERM policy needs to authorize and give authority to the development and ongoing maintenance of the organization’s risk taxonomy. The highest level structure for risk management should be included in the policy – such as the establishment of risk oversight for areas such as financial/treasury, operational, and legal/compliance risks. The policy should reference and give authority to the establishment of another document that defines the depth of the structure of risk categories that the organization recognizes and manages.

• Risk Ownership. You cannot hold anyone accountable for risk unless clear ownership of risk id defined. While specific ownership of individual risks are found in supporting risk management policies (e.g., vendor risk policy, privacy policy, credit risk policy, information risk policy) – the ERM policy should state the ownership of risk at the high-level categories defined in the risk taxonomy. It should also be clear on the point that the risk management function does not own risk, the business and process owners are the ones that own risk. The ERM process is there to communicate and provide the infrastructure to manage and monitor risk to support the risk owners across the business.

• Risk Assessment Process. The ERM policy is to authorize the formation of risk assessment processes in the organization. The policy itself should outline the expectations of required periodic assessments such as an annual ERM assessment process, and is to authorize the establishment of more specific risk assessments that are established in supporting risk management policies. This section of the policy should identify the approval needed to establish a risk assessment, what structure is provided, and how the assessment gets communicated and integrated into the ERM structure.

• Risk Infrastructure, Documentation. & Communication. Documentation of risk, risk taking, as well as assessment, management, and monitoring activities for risk are critical to a successful ERM program. An organization cannot hold individuals accountable for risk taking if there is not clear documentation on the risk. This section should authorize the establishment of an enterprise platform to monitor ongoing risk management processes across the organization. It should also establish a warning against the use of technologies such as spreadsheets for risk assessments that lack proper audit trails.

• Mitigation & Response. The ERM policy should articulate the proper response plans to risk such as risk transfer, risk acceptance, risk mitigation, and risk avoidance. While much of the details of this will be worked out in supporting risk policies, it is in the ERM policy that the are defined at a high level.

• Key Risk Indicators. Ongoing monitoring for risk is critical to a successful ERM program. This involves the authorization and establishment of a process to gather metrics on Key Risk Indicators that are further defined in supporting policies. The ERM policy should provide guidance on how KRI information is collected, how often, and establish that KRI’s are to be relevant to the business and mapped to Key Performance Indicators of the business.

• Risk Training. Everyone in the organization has some role in risk management – it is necessary that risk culture, risk taking, and risk responsibilities be clearly understood at all levels of the business for the various business roles and the risks they encounter and manage. The ERM policy establishes an ongoing risk training and awareness program to communicate and educate risk to employees, stakeholders, and business partners.

• Risk Budgets/Funding. The ERM policy should establish and authorize the financing for risk management and oversight activities. This ties into other sections of the ERM policy as well as supporting policies to clearly define what budget areas various risk activities will be financed from.

• Risk Activities (calendar). The
  ERM policy should establish what activities are required of ERM on an ongoing/calendar basis. This should include monthly/quarterly/annual reports and assessments, the individuals responsible for them, and who they get communicated to. One of the best examples I have seen of this is at Microsoft in what they have called ‘The Rhythm of Risk’ in which risk management is aligned to the needs of the board and executives based on their quarterly and monthly calendars.

• Definitions. Finally, as with all policies, a section is needed that clearly defines definitions related to risk and risk management. I highly encourage the use of standard definitions such as those in ISO 31000:2009 and ISO:IEC 73.

As I stated before, no two risk management policies are alike. What I have provided here is some guidance on the sections I most often include in developing an ERM policy (as well as supporting risk policies). There are other standard sections to policies such as revision history I have not included for the sake of simplicity.

I would love to hear your thoughts on the topic of ERM policies. Please feel free to comment in this forum, or send me an e-mail. If anyone seeks further help in writing, reviewing, and/or revising their risk policies please do not hesitate to contact me.

My response to Steven Minsky’s blog on: ERM vs GRC? SEC Says No to Myopic Approach: Costly Example from Goldman Sachs