Making Sense of GRC Related Technology & Solutions

Every organization does GRC (governance, risk management, and compliance), but it does not mean that every organization does GRC well. Complicating this is a maze of GRC technologies. Some are built to solve very specific problems, others focus on department/function wide management of GRC related activities, some are enterprise platforms for a specific purpose (e.g., enterprise policy management, third party management, risk management). And some are Enterprise GRC platforms to try to bring everything together in a single architecture. But then many fail, often watering down GRC to the lowest common denominator and frustrating those in the trenches of business and the back-office of GRC. As a result, many organizations have begun approaching GRC architecture and allowing for a core system to be the hub that integrates with best of breed GRC solutions where they make sense.

Adding to this is the maze of over 800 GRC technology solutions in the market across 17 primary segments of GRC domains with many sub-segments in each. The primary segments are:

  • Enterprise GRC Platforms. Capability to manage an integrated architecture across multiple GRC areas in a structured strategy, process, information and technology architecture (see How to Purchase Enterprise GRC Platforms).
  • Audit Management & Analytics. Capability to manage audit planning, staff, documentation, execution/field work, findings, reporting, and analytics (see How to Purchase Audit Management Solutions & Platforms).
  • Automated Control Enforcement & Monitoring. Capability to automate the detection and enforcement of internal controls in business processes, systems, records, transactions, documents, and information.
  • Business Continuity Management. Capability to manage, maintain, and test continuity and disaster plans, and implement these plans expected and unexpected disruptions to all areas of operation.
  • Compliance Management. Capability to manage an overall compliance program, document and manage change to obligations, assess compliance, remediate non-compliance, and report (see How to Purchase Compliance Management Solutions & Platforms).
  • Environmental Management. Capability to document, monitor, assess, analyze, record, and report on environmental activities and compliance.
  • Health & Safety Management. Capability to manage, document, monitor, assess, report, and address incidents related to the health and safety of the workforce and workplace.
  • Internal Control Management. Capability to manage, define, document, map, monitor, test, assess, and report on internal controls of the organization.
  • IT GRC Management. Capability to govern IT in context of business objectives and manage IT process, technology, and information risk and compliance (see How to Purchase IT GRC Management Solutions & Platforms).
  • Issue Reporting & Management. Capability to notify on issues and incidents and manage, document, resolve, and report on the range of complaints, issues, incidents, events, investigations, and cases.
  • Legal Management. Capability to manage, monitor, and report on the organization’s legal operations, processes, matters, risks, and activities.
  • Physical Security Management. Capability to manage risk and losses to individuals and physical assets, facilities, inventory, and other property.
  • Policy & Training Management. Capability to mange the development, approval, distribution, communication, forms, maintenance, and records of policies, procedures and related awareness activities (see How to Purchase Policy Management Solutions & Platforms).
  • Quality Management. Capability to manage, assess, record, benchmark, and track activity, issues, failures, recalls, and improvement related to product and service quality.
  • Risk Management. Capability to identify, assess, measure, treat, manage, monitor, and report on risks to objectives, divisions, departments, processes, assets, and projects (see How to Purchase Risk Management Solutions & Platforms).
  • Strategy & Performance Management. Capability to govern, define, and manage strategic, financial, and operational objectives and related performance and risk activities.
  • Third Party Management. Capability to govern, manage, and monitor the array of 3rd party relationships in the enterprise, particularly risk and compliance challenges these relationships bring (see How to Purchase 3rd Party Management Solutions & Platforms).

While there is such a breadth of GRC related solutions in the market, many organizations are still encumbered by a labyrinth of chaos in manual processes using documents, spreadsheets, and emails for many of these areas. The disconnected silos of manual GRC processes encumbered with documents, spreadsheets and emails are not sustainable and lead to exposure, failure, and loss. Unfortunately, organizations are quick to react to this and often find themselves neck deep in a GRC platform rollout before thinking through their overall strategy, process, information, and technology needs.

The problem with how many organizations approach GRC (remember, everyone does GRC whether you use the acronym or not) is that it has not been designed properly, particularly when it has been designed around the capabilities of a specific platform. Too often organizations are letting a GRC platform define their GRC strategy instead of letting their GRC strategy shape their GRC platform and architecture. Organizations end up with significant risk gaps within their operating models despite significant investment in ‘leading’ GRC platforms that are scattered and disconnected across the business. This has resulted in a poor return on investment in GRC related projects that fail to drive value or opportunity that GRC transparency should create.

GRC projects fail when:

  • Lack of a GRC strategy and understanding of processes.
  • Letting a GRC solution/platform define your GRC strategy, processes, and information.
  • GRC platforms that under deliver to the range of needs and processes.
  • Trying to meet the needs of departments with a solution that is not flexible that forces everyone to manage GRC to the lowest common denominator.
  • The needs of one department with budget overshadow the needs of other departments.
  • GRC platform implementation that goes over budget and misses deadlines while draining resources.
  • GRC platforms that require extensive and costly build-out to achieve capabilities the organization thought were native in the product.
  • GRC platform that does not integrate well with other systems.

Organizations that have went down the wrong path with a GRC technology strategy may be ready to throw in the towel and call it quits. The truth is the organization can never abandon GRC as it is something every organization does.  It may be done poorly, it may be done well, but every organization does GRC if they call it GRC or something else. While a technology strategy and GRC platform may be scrapped and the organization may retreat to old manual processes, it does not change the fact that the organization has a duty and responsibility for GRC.

There are a couple of key upcoming events to be aware of that can assist organizations on their GRC strategy and the role of technology in that strategy, these are:

  • Findings from the OCEG GRC Technology Strategy Survey. OCEG engages GRC 20/20 to design this survey, analyze the findings, and build the written report. The webcast for this survey is on January 21st.
  • State of the GRC Market Research Briefing. This is GRC 20/20’s flagship Research Briefing that is 2 hours in length and goes into the details of drivers and trends in GRC, market segmentation and forecasting, RFP scopes and trends, and buyer inquiries and what organizations are looking for. This is on February 1st.
  • Enterprise GRC by Design Workshop. This workshop aims to provide a blueprint for attendees on effective enterprise GRC strategies in a dynamic business, regulatory, and risk environment. Attendees will learn enterprise GRC strategies and techniques that can be applied across the organization. The next one is in Rhode Island, CT, USA on February 18th.

Spreadsheets in Financial Control Processes

Also GRC 20/20 is working on a specific research project focusing on the regulatory scrutiny (e.g., SOX) of spreadsheets in financial control processes.  Organizations are facing increased pressures to ensure that they have adequate controls over end user computing controls, particularly spreadsheets. This is very apparent when spreadsheets are used as part of accounting processes. The Public Company Accounting Oversight Board (PCAOB) has requested auditors to increase their focus on ‘System Generated Data and Reports’ driving the application of so-called ‘enhanced audits’ of Sarbanes Oxley (SOX) control processes. This scrutiny is leading to new SOX failings for companies that had previously had no such failings. In particular, these enhanced audits are exposing the role of spreadsheets in context of Internal Control over Financial Reporting (ICFR) and the fact that such spreadsheet controls are often open to manual manipulation.

This survey is intended to gather organization awareness and concern of spreadsheet controls in context of ICFR, audits and PCAOB scrutiny.

[button class=”kopa-button big-button color-button” link=”” target=””]TAKE SURVEY[/button]

Best Practice in Model Risk Management: Modeling Your Models

What is a Model?

By definition, a model is a mathematical approximation of scenarios that is used to analyze and forecast prices, events, risks, relationships, and future outcomes.  It is formally defined as “a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates.”[1. While there are several related regulatory guidance and notices, the core guidance is found in OCC SR-11-7, Supervisory Guidance on Model Risk Management (  The Federal Reserve has similar guidance (  Most recently, the OCC released requirements in its publication Dodd-Frank Act Stress Testing (DFAST) Reporting Instructions OCC Reporting Form DFAST-14A December 2014]

Models are used across industries to analyze, predict, and represent performance and outcomes that impact operations and business strategy. A range of departments, functions, and roles rely on models as a critical foundation of business processes that support long-term strategic planning as well as day-to-day tactical decisions. They are used pervasively to:

  • Analyze business strategies
  • Inform decisions
  • Identify and measure risk
  • Value exposure in financial products or positions
  • Conduct stress testing
  • Assess adequacy of capital
  • Manage client assets
  • Comply to internal limits
  • Measure and maintain controls and oversight
  • Meet financial and regulatory reporting requirements
  • Provide input into public disclosures.

When Models Fail

While the common understanding of models is that they have three components – input, processing and reporting – the reality is that there are multiple parts to each of these component areas.  Multiple components within input, processing, and reporting connect to each other and have an array of data and analytics.  Adding to this complexity is the human and process elements intertwined throughout the business use of models that weave together a variety of manual processing and technology integration elements needed to run the model.

Organizations have become highly dependent upon models to support critical business processes and decisions. However, models come with risks when internal errors or misuse results in bad decisions. Model risk is the potential for adverse consequences from decisions based on incorrect or misused models and leads to financial loss, poor business and strategic decision-making, and damage to a financial service organization’s brand. It is ironic that the very tools often used to model and predict risk can be a significant risk exposure themselves.

Models, inappropriately used and controlled, bring a number of risks to the organization, because of:

  • Dynamic and changing risk and business environments.
  • Lack of governance and control of models and their components (e.g., spreadsheets).
  • Not understanding the variety of inputs beyond the processing component of the model.
  • Errors in input, processing, and reporting.
  • Misuse of models for purposes they were not designed for.
  • Misrepresentation of reality within models.
  • Limitations in the models.
  • Pervasiveness of models and their use.
  • Big data and GRC interconnectedness.
  • Inconsistent development and validation of models.

Increasing Pressure on Model Risk Management

Increasing model risk combined with a cavalier approach to models has led to increasing regulatory requirements and scrutiny in the governance and use of models. The Federal Reserve Comprehensive Capital Analysis and Review (CCAR)[2.] has taken into account the growth and use of models and the need for greater regulatory oversight. Most recently, the OCC released detailed model governance and risk management requirements in December 2014: Dodd-Frank Act Stress Testing (DFAST) Reporting Instructions OCC Reporting Form DFAST-14A December 2014.[3.] This has further defined requirements for model risk management and specifically calls out the scope of end user computing applications in model risk.

A Firm Foundation for Model Risk Management

Model governance and risk management has not historically been a strategic priority for organizations. Without a structure to govern models, risk exposure has grown and the result is increasing regulatory pressure.  Organizations should not see model risk management as simply a regulatory obligation; model governance enables strategic decision-making and performance management.

To effectively manage model risk, organizations need a structured approach to:

  • Model risk governance. A well-defined model governance framework to manage model risk that brings together the right roles, policies, and inventory.
  • Model risk management lifecycle. An end-to-end model risk management lifecycle to manage and govern models from their development, throughout their use in the environment, including their maintenance and retirement.
  • Model risk management architecture.  Effective management of model risk in today’s complex and dynamic business environment requires an information and technology architecture that enables model risk management.

Best Practice: Organizations Need to ‘Model’ their Models

Models are complex and have a plethora of data and technology pieces.  Being able to document these pieces and layout how they function and operate together has become critical to maintaining a model inventory and documentation.  The mature model risk management program will leverage enterprise architecture and business modeling technologies to provide an accurate model inventory with detailed documentation of the components and how they function.

Utilizing enterprise architecture and business modeling technologies allows the organization to define all the pieces to models, maintain an accurate model inventory, ensure that models are built from standard and approved IT components and identify where exceptions lie, and provide a visual representation and documentation of the model and how it functions.  It is through the ability to ‘model’ the models that the organization then accurately manages information and technology architecture for model risk management.

Have a question? If you are an organization that is facing the challenges of Model Risk Management, utilize GRC 20/20 to get your questions answered.  As part of our research we offer complimentary inquiries to get your question answered and point you in the direction of who provides the write technology and solutions to solve your model risk management needs.

[button link=”” color=”default”]SUBMIT INQUIRY[/button]

Want to read more?  This post by The GRC Pundit is from a longer research piece on Model Risk Management in the Financial Services Industry.

[button link=”” color=”default”]READ MORE[/button]


The Agile Organization: GRC as a Transformational Process

Today, the organization is not only complex, but also chaotic in a constant state of metamorphosis. The organization is:

  • Distributed. Business is not done within traditional brick-and-mortar walls as it now has distributed operations complicated by a web of global business partner and client relationships. Physical buildings and conventional employees no longer define an organization. The organization is an interconnected mesh of relationships and interactions that span traditional business boundaries.
  • Dynamic. Organizations are in a constant state of metamorphosis. The organization has to manage shifting business strategy, technology, and processes while keeping current with changes to risk and regulatory environments around the world. Not only is the organization dealing with constant change in its business relationships, each individual relationship is dealing with change in its business and downstream relationships.
  • Disrupted. The intersection of distributed and dynamic business brings disruption. The velocity, variety, and volume of change is overwhelming – disrupting the organization and slowing it down at a time when it needs to be agile and fast. Business operates in a world of chaos. Applying chaos theory to business is like the ‘butterfly-effect’ in which a small event actually results, develops and influences what ends up being a significant event.

The primary challenge of the organization is a need to be agile in a distributed, dynamic, and disrupted environment. Agility and control naturally seem to be opposing forces . . .

Continued on the MEGA Corporate Governance Blog (The GRC Pundit is a guest blogger) . . .

[button link=”″ color=”default”]READ MORE[/button]