Category: Blogs

Considerations When Purchasing GRC Solutions

The GRC Pundit BlogPublished on2 Comments on Considerations When Purchasing GRC Solutions

Every organization does GRC. . .

It makes no difference whether you use the acronym ‘GRC’ or not, every organization has some approach to governance, risk management, and compliance. Your organization’s approach to GRC may be:

  • Ad hoc and fly by the seat of your pants;
  • Decentralized and siloed; or,
  • Collaborative and integrated.

No matter an organizations approach to GRC, the use of technology is pervasive in GRC processes. Technology for GRC can be using documents, spreadsheets, and emails; or in focused applications deployed to meet specific GRC needs; or in enterprise GRC platforms and architectures that pull many functions together.

GRC 20/20 Research is deeply focused on analyzing, monitoring, differentiating, and forecasting the market for GRC solutions. In this context I have mapped over 600 solutions into the GRC market.  These include solutions focused on specific areas of GRC (e.g., policy management, investigations, health & safety, legal matters, third party management) to GRC platforms that bring multiple modules together at a department or enterprise level. In the course of an average week, GRC 20/20 answers between 5 and 10 inquiries from organizations looking for GRC related solutions and assists many organizations in RFP development, management, and evaluation of solutions.

Over the next few months I will be doing a regular series of posts on buying considerations in different areas of GRC. However, before getting into specific areas, I want to share considerations organizations should have when looking at any type of GRC related solution.  The guidance provided below is applicable whether you are looking for something very narrow such as occupational health & safety, or very broad such as enterprise GRC platforms.

When considering GRC related solutions, organizations should:

  • Think GRC Architecture and not GRC Platform. There is no GRC silver bullet that does everything. Solution providers may sincerely think they can do it all but they do not. Yes, there can be a core platform that becomes the hub of GRC integration and reporting but it is often not the only GRC solution involved. Organizations often have several GRC related solutions deployed for different purposes. Just this past week I had dinner with individuals from three major financial services organizations that all had deployed one solution for operational risk management and another for IT GRC. I have been seeing this for years. Organizations are too focused on trying to find one platform to be all things and then find they have watered down areas of GRC and forced different GRC groups to work to the lowest common GRC denominator.
  • Be Diligent in Checking Client References. Ask the hard questions. Push them to find out what they do not like about the solution, find out where it has under-delivered, how issues were responded to. Understand that when solution providers give you a reference it is usually vetted and it is a decision-maker that purchased the product that has a vested interest in the product, and the solution provider treats them like royalty. I talk to these references, but I also insist on talking to someone else who uses the solution on a daily basis on a separate call without others on the line. Often the decision-maker will sing the solution’s praises on the first call and the other call you will hear the truth of the implementation and frustration with the solution.
  • Be Wary of the RFP “Yes, We Do That” Responses. This really frustrates me. Some solution providers basically answer ‘yes’ to nearly every criteria in an RFP. They simply believe it is a matter of ‘configuring’ their solution to support this requirement. They do not tell you it will be a six-month project to do configure it for this feature. This is why organizations have to get solutions and test drive it themselves. I have gotten to the point that I add a field in RFPs that asks if it is a native feature existing out of the box in the solution or if it is something that has to be configured and built-out.
  • Know the Solution Provider’s Expertise. A common complaint I am getting these days is that the GRC solution providers developers have no clue on GRC. Some of the most basic fundamentals of risk management have to be explained over and over again. Everything sounded great throughout the sales process, but as soon as the deal was closed and the implementation begun the implementation team and supporting developers are ignorant of GRC concepts. Make sure that you have a good understanding of the implementation team expertise and background in GRC and the developers supporting that team.  Note, I have stated developers a few times, several of the leading solutions are very bespoke and require a lot of build out for each implementation.
  • Be Cautious with Analyst Rankings and Advise. In full disclosure – I am an analyst. I spent seven years at Forrester and now eight on my own. My concern over analyst reports and rankings is growing at an alarming rate. The recent series of Magic Quadrants from Gartner has put me into a state of shock. Organizations rely on these reports to make decisions. Yes, Gartner has a veiled warning that solutions in the upper right may not be the best fit for all organizations. Still, the perception and ranking marks the ones in the furthest upper right as the best. Some advice:
    • Consider Solutions Beyond the ‘Leaders.’ I hate the two-dimensional rankings of the Forrester Wave and Gartner Magic Quadrant. There is a natural assumption that those in the upper right are the best solutions when reality it is someone in the lower left or not even in the report that may be the best fit for your organization. Many solutions cannot even get into the Gartner and Forrester reports based on their criteria for number of offices, global presence, and revenue. These are still very capable solutions and often are more agile and using newer and more innovative technologies with better user interfaces. A good RFP and evaluation often has a mixture of those evaluated and ranked highly by major analyst firms as well as a few that are not covered or did not score as highly.
    • Gartner does not publish criteria. Seriously, why can’t this be transparent? I guess this is the magic in the magic quadrant as Gartner does not want anyone to know the criteria and scores of each solution. A research organization should be able to publish its criteria, methodology, and scores or it should not call itself a research organization. Forrester does publish criteria and scores though they have been rolling up GRC Waves and it has become very high-level and lacks usefulness.
    • Reliance on video demos and questionnaires. Gartner does not have a consistent process for Magic Quadrants across their research, and even in the range of GRC Magic Quadrants they just published there is variance. However, the general approach for the recent series of GRC Magic Quadrants has been having GRC solution providers fill out a survey questionnaire and submit a video demo of the solution. For some Magic Quadrants they did not dig deeper than this. Companies are investing hundreds of thousands of dollars in GRC solutions based on Gartner rankings which in turn are based on a video demo and survey. This simply turns the Magic Quadrant process into a video beauty pageant.
    • Client references done by surveys. On top of this, Gartner did online client surveys for reference checks and randomly called a few to fact check responses. This is ridiculous. Subscribers pay tens of thousands of dollars for research access. Gartner sells redistribution rights to Magic Quadrants to vendors for thousands of dollars. Organizations are making big purchasing decisions based on these reports. Get on the phone and talk to all the client references and grill them, don’t just send them survey questions. BTW, Gartner’s day rate for consulting is over $15,000 a day which is higher than most Wall Street lawyers. Earn your money and get on the phone with clients and roll-up your sleeves and dig deep into the solutions.
    • Rankings that simply do not make sense. I look at the Magic Quadrant graphic for operational risk management and scratch my head in bewilderment. The plotting is a mystery to me. Some marked as Leaders have deep operational analytic capabilities, they have operational loss data and metrics tied to loss databases aggregating industry loss information to go into capital modeling for operational risk. These are solid solutions. Then you have others in the Leaders category that barely skim the surface of operational risk management with limited analytical capabilities. These are apples and oranges. Those that have very deep operational risk capabilities are being plotted next to others that have limited capabilities. I guess that is to be expected when evaluation is being done by submitting a video demo and questionnaire. Under those circumstances anything can be made to look better – it is like airbrushing magazine models. This was again verified this past week at the dinner I referenced above, all three major financial services firms picked one of the leaders for operational risk management because of their deep operational risk analytic capabilities while not choosing the incumbent already being used for IT GRC which scores further in the upper right in Gartner’s operational risk Magic Quadrant. Go figure . . . I could state the same for the IT Risk Management Magic Quadrant.

This is some collected advice and experience I have from a few decades of experience. What is your experience and advice to organizations in evaluating solutions related to GRC?

Best Practice in Model Risk Management: Modeling Your Models

Risk Management Solutions, The GRC Pundit BlogPublished onLeave a Comment on 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 (http://www.occ.treas.gov/news-issuances/bulletins/2011/bulletin-2011-12a.pdf).  The Federal Reserve has similar guidance (http://www.federalreserve.gov/bankinforeg/srletters/sr1107a1.pdf).  Most recently, the OCC released requirements in its publication Dodd-Frank Act Stress Testing (DFAST) Reporting Instructions OCC Reporting Form DFAST-14A December 2014 http://www.occ.gov/tools-forms/forms/bank-operations/DFAST-14A-Template-Instructions.pdf.]

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. http://www.federalreserve.gov/bankinforeg/ccar.htm] 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. http://www.occ.gov/tools-forms/forms/bank-operations/DFAST-14A-Template-Instructions.pdf] 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=”http://grc2020test.cloudaccess.host/inquiry-submission/” 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=”http://grc2020test.cloudaccess.host/2015/04/01/1601/” color=”default”]READ MORE[/button]

 

The Agile Organization: GRC as a Transformational Process

GRC Platforms & Architecture Solutions, The GRC Pundit BlogPublished onLeave a Comment on The Agile Organization: GRC as a Transformational Process

Business is complex; gone are the years of simplicity in business operations. Exponential growth, globalization, distributed operations, changing processes, competitive velocity, complex business relationships, disruptive technology, multiplying regulations, and explosion of business data encumbers organizations of all sizes. Keeping complexity and change in sync is a significant challenge for boards and executives, as well as all levels of business operations.

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=”http://community.mega.com/t5/Blog/The-Agile-Organization-GRC-as-a-Transformational-Process/ba-p/10605″ color=”default”]READ MORE[/button]

Regulatory Change Management Maturity Model: From Ad Hoc to Agile

Compliance Management Solutions, Policy & Training Management Solutions, The GRC Pundit BlogPublished onLeave a Comment on Regulatory Change Management Maturity Model: From Ad Hoc to Agile

This is part 5 and final post in the series on regulatory change management, part of the broader series of posts on the Greatest GRC Challenges companies are facing today.  Next we will look at changing risk environments.  In the previous posts we explored:

In this post I detail GRC 20/20’s maturity model to measure regulatory change management programs to support an efficient, effective, and agile process. These posts are excerpts from the broader GRC 20/20 Research Paper: Regulatory Change Management: Effectively Managing Regulatory Change

Mature regulatory change management requires the organization to align on regulatory risk. It also involves participation across the organization at all levels to identify and monitor uncertainty and the impact of regulatory change.

GRC 20/20 has developed the Regulatory Change Management Maturity Model to determine an organization’s maturity in regulatory change management processes as well as information and technology architecture.

The GRC 20/20 Regulatory Change Management Maturity Model is summarized as follows:

Level 1 – Ad Hoc

Organizations at this stage lack a structured approach to regulatory change management and are constantly putting out fires and being caught off guard. Few if any resources are allocated to monitor regulatory change. The organization addresses regulatory change in a reactive mode—doing assessments when forced to. There is no ownership or monitoring of regulatory change and certainly no integration of regulatory change information and processes. Characteristics of this stage are:

  • Lack of a defined regulatory taxonomy
  • Ad hoc and reactive approaches to regulatory and business change
  • Document and email-centric approaches
  • Lack of accountability

Level 2 – Fragmented

In the Fragmented stage, departments are focused on regulatory change management within respective functions—but information and processes are highly redundant. The organization may have limited processes for regulatory change but largely does not benefit from the efficiencies of an integrated approach. Regulatory change management is very document-centric and lacks an integrated process, information and technology architecture. Positively, there is some structure to regulatory change responsibilities—but the management of regulatory change lacks accountability as it is done largely in documents and email that lack structures of accountability and automation. Characteristics of this stage are:

  • Varied approaches to regulatory change
  • Lack consistent structure
  • Lack integration or formal processes for sharing regulatory information
  • Reliance on fragmented technology with a focus on discrete documents

Level 3 – Managed

The Managed stage represents a mature regulatory change management program that is using technology for structured workflow, task management, and accountability. Regulatory change functions have defined processes for regulatory change management, an integrated information architecture supported by technology and ongoing reporting, accountability, and oversight. Though there is no integration of regulatory content feeds into the technology platform. Characteristics of this stage are:

  • Visibility into regulatory change across the business
  • Established processes for regulatory change
  • Good use of technology to manage accountability

Level 4 – Integrated

It is at the integrated stage that the organization begins to integrate regulatory content feeds into the technology platform for automation. The organization has consistent regulatory taxonomy, process, information, and technology to streamline regulatory change management processes. The organization is seeing gains in addressing regulatory change through shared information that achieves greater agility, efficiency and effectiveness in a common technology architecture that enables consistent management of regulatory change. Standardized workflow is integrated into regulatory and legal content feeds. Characteristics of this stage are:

  • Strategic approach to regulatory change across departments
  • Common process, technology and information architecture
  • Integration of legal/regulatory content feeds
  • Reporting across departments

Level 5 – Agile

At the Agile stage, the organization has completely moved to an integrated approach to regulatory change management across the organization. This results in a shared-services approach in which core regulatory change technology, content, and processes are shared centrally. The approach is characterized through a mature regulatory taxonomy with integrated and actionable regulatory content automated by technology. The organization has enterprise workflow that provides business-process automation for regulatory change with oversight and management of regulatory change. Regulatory content feeds deliver fully analyzed content that identifies relevancy, impacts and tasks. Characteristics of this stage are:

  • Regulatory intelligence achieved through integration of analyzed content and enterprise technology
  • Consistent views of regulatory change and impact on operations and policies
  • Able to efficiently manage business change in regulatory context

GRC 20/20’s Final Perspective

The constant changes in today’s regulatory environments translate to a growing burden on organizations in terms of the number of regulations they face and their scope. Many organizations do not possess the necessary regulatory change management infrastructure and processes to address these changes and, consequently, find themselves at a competitive disadvantage and subject to regulatory scrutiny and losses that were preventable. These organizations can greatly benefit from moving away from manual and ad hoc process changes and toward a system specifically designed to manage those changes comprehensively and consistently. Such a system gathers and sorts relevant information, routes critical information to subject matter experts, models and measures potential impact on the organization, and establishes personal accountability for action or inaction.

 

Exploring the New Frontiers Between Legal and GRC

Compliance Management Solutions, GRC Platforms & Architecture Solutions, GRC Pundit TV, Legal Management SolutionsPublished onLeave a Comment on Exploring the New Frontiers Between Legal and GRC

GRC Architecture to Manage Regulatory Change

The GRC Pundit BlogPublished on1 Comment on GRC Architecture to Manage Regulatory Change

This is part 4 on the topic of regulatory change management.  In the previous posts we explored:

In this post I detail the information and technology architecture needed to support an efficient, effective, and agile regulatory change management process. These posts are excerpts from the broader GRC 20/20 Research Paper: Regulatory Change Management: Effectively Managing Regulatory Change

Effectively managing regulatory change is done with a GRC information and technology architecture to improve processes and transform manual document and email-centric processes. Organizations use technology to document, communicate, report, monitor change, and facilitate business impact analysis.

 

Regulatory Change Management Architecture Goals

A GRC information and technology architecture helps the organization to manage regulatory change to:

  • Ensure that ownership and accountability of regulatory change is clearly established and understood.
  • Manage ongoing business impact analysis and scoring.
  • Integrate regulatory intelligence feeds that kick-off workflows and tasks to the right SME when change occurs that impacts the organization.
  • Monitor the internal organization’s environment for business, employee, and process change that could impact the firm’s state of compliance.
  • Identify changes in risk, policy, training, process, and control profiles based on regulatory change assessments.
  • Visualize the impact of a change on the organization’s processes and operations.

The right GRC information and technology architecture allows compliance and regulatory experts to profile regulations, link with external content feeds and content aggregators, and push new developments or alerts into the application and disseminate for review and analysis. It delivers effectiveness and efficiency using technology for workflow, task management, and accountability documentation—allowing the organization to be agile amidst change. It enables the organization to harness internal and external information and be intelligent about regulatory environments across the organization.

Regulatory Change Management Architecture Considerations

In evaluating regulatory change management solutions that integrate regulatory intelligence feeds and technology, organizations should ask the following three questions:

  1. How adaptable is the regulatory taxonomy?  The regulatory taxonomy provides the backbone of regulatory change management as it maps regulations to other objects such as business processes, assets, subject matter experts, risks, controls, policies and more. Organizations should specifically understand how adaptable the taxonomy/mapping is to fit the organization’s environment, evolve as the business evolves, and how easy it is to adapt the metadata and taxonomy structure.
  2. How rich is the regulatory content? A lot of GRC solutions can handle the workflow and task management of regulatory change management. What really differentiates capabilities is the depth and breadth of the regulatory intelligence content feeds that the solution offers. This includes regulator coverage, geographic coverage, supporting news and analysis, frequency of updates, and actionable content/recommendations.
  3. How strong is the technology? As stated, a lot of solutions can do workflow and tasks management for regulatory change, so the evaluation of the technology itself needs to go deeper in the systems ability to integrate regulatory intelligence feeds, conduct business impact analysis, as well as connect and understand relationships of regulatory impact to policies, processes, and risks. Of particular importance is the user experience.  SMEs across the enterprise may or may not be technical gurus; the overall user experience should be intuitive and natural.
    • Deficient technology involves documents and spreadsheets with email used as a workflow and task management tools. The organization struggles with things getting missed and not having a structured system of accountability.
    • Moderate technology provides a system of accountability with basic workflow and task management, but the integration of regulatory developments/updates is a manual entry system that is time-consuming and taxing on resources.
    • Strong technology for regulatory change management has enterprise content, workflow and task management capabilities with integration to actionable regulatory content.  It enables a closed-loop process as it delivers and integrates regulatory content and insight with technology in an integrated architecture. It also allows the indexing and mapping of regulations to other GRC elements.

Regulatory Change Management Architecture Capabilities

All of these elements are critical and are why they come together in a GRC architecture or platform for regulatory change management. Some solutions in the GRC space are delivering across these three elements and are being used to gather regulatory information, weed out irrelevant information, and route critical information to SMEs responsible for making a decision on a particular topic. This at a minimum requires workflow and task management capabilities, but in mature systems it provides direct integration with regulatory content aggregators. These aggregators manage regulatory profiles, and provide data about relevant new developments that can be routed to individuals responsible for evaluating specific regulatory subject areas. Advanced solutions map regulatory changes to the appropriate metadata as part of a fully integrated, dynamic, and agile process.

Specific capabilities to be evaluated in a GRC solution for regulatory change management, include:

  • Regulatory intelligence content.  At a very basic level, the solution should allow for simple manual entry of new changes and updates so they can be routed to the correct SME for analysis. More advanced solutions provide the interface to content to search for related laws, statutes, regulations, case rulings, analysis, news, and information that intersect with the change and could indicate regulatory risks that need to be monitored actively. The solution needs to automatically capture and access regulatory related information and events from various external sources that are flagged as relevant to the business. This capability helps ensure that regulatory affairs and compliance teams are up-to-date on new, changing, or evolving regulatory requirements. Regulatory intelligence feeds should be easily configured and categorized in the regulatory taxonomy, providing a powerful and comprehensive inventory of changes in laws and regulations. The regulatory content should identify information such as geographic area/jurisdiction, issuing regulatory body, subject, effective date, modification date, end date, title, text, and guidance for compliance. The guidance should give commentary on how regulatory alerts are effectively transformed from rules into actionable tasks and modifications to internal policies and processes.
  • Content management. The solution should be able to catalog and version regulations, policies, risks, controls and other related information. It should maintain a full history of how the organization addressed the area in the past, with the ability to draft new policies, assessments, and other compliance responses for approval before implementation. The solution needs to provide a central repository for storing and organizing all types of regulations and laws based on various templates and classification criteria, within a defined taxonomy. The system should be able to maintain a history of actions taken and analysis, including review periods, and obsolescence rules that can be set for regulations.
  • Process management. A primary directive of a defined regulatory change management process is to provide accountability. Accountability needs to be tracked as regulatory change information is routed to the right SME to take review and define actions. The SME should be notified that there is something to evaluate and given a deadline based on an initial criticality ranking. The SME must be able to reroute the task if it was improperly assigned or forward it to others for input. Individuals and/or groups of SMEs must have visibility into their assignments and time frames. The built-in automatic notification and alert functionality with configurable workflows facilitates regulatory change management in the context of the organization’s operations.
  • Business impact analysis. The system needs to provide functionality to identify the impact of changes of regulations on the business environment and its operations and then communicate to relevant areas of the organization how the change impacts them. This is conducted through a detailed business impact analysis in the platform and is facilitated by being able to tag regulatory areas/domains to respective businesses and products. The overall system needs to be able to keep track of changes by assessing their impact, and triggering preventive and corrective actions. Furthermore, the solution should ensure that stakeholders and owners are informed, tasks related to actions are assigned, and due dates for the completion of actions/tasks are defined. Similarly, when regulations are removed, repealed or deactivated, the solution assesses the impact of the change, and sets up the appropriate responsive actions.
  • Mapping regulations to risks, policies, controls and more. A critical component to evaluate is the solution’s ability to link regulations to internal policies, risks, controls, training, reports, assessments, and processes. The ability to map to business lines, products, and geographies allows companies to manage a risk-based approach to regulatory compliance. The workflow, defined above, automatically alerts relevant stakeholders for necessary action and process changes. It also supports electronic sign-offs at departmental and functional levels that roll up for executive certifications.
  • Ease of use. Regulatory experts are not typically technical experts. The platform managing risk and regulatory change has to be easy to use and should support and enforce the business process. Tasks and information presented to the user should be relevant to their specific role and assignments.
  • Audit trail and accountability. It is absolutely necessary that the regulatory change management solution have a full audit trail to see who was assigned a task, what they did, what was noted and if notes were updated, and be able to track what was changed. This enables the organization to provide full accountability and insight into whom, how, and when regulations were reviewed, measure the impact on the organization, and record what actions were recommended or taken.
  • Reporting capabilities. The solution is to provide full reporting and dashboard capabilities to see what changes have been monitored, who is assigned what tasks, which items are overdue, what the most significant risk changes impacting the organization are and more. Additionally, by linking regulatory requirements to the various other aspects of the platform including risks, policies, controls and more, the reporting should provide an aggregate view of a regulatory requirement across multiple organization units and business processes.
  • Flexibility and configuration. No two organizations are identical in their processes, risk taxonomy, applicable regulations, structure, and responsibilities. The information collected may vary from organization to organization as well as the process, workflow, and tasks. The system must be fully configurable and flexible to model the specific organization’s risk and regulatory intelligence process.

Defining a Regulatory Change Management Process

The GRC Pundit BlogPublished on4 Comments on Defining a Regulatory Change Management Process

This is part 3 on the topic of regulatory change management.  In the previous posts we explored the pressure organizations are under in context of regulatory change, in this post we look at what elements are needed in an efficient, effective, and agile regulatory change management process.

processOrganizations are struggling with regulatory change and seeking to integrate technology with actionable and relevant regulatory change content to support consistent regulatory change processes. A dynamic business environment requires a process to actively manage regulatory change and fluctuating risks impacting the organization. The old paradigm of uncoordinated regulatory change management is a disaster given the volume of regulatory information, the pace of change, and the broader operational impact on today’s risk environment.

Elements of a Regulatory Change Management Process

Regulatory change management requires a process to gather information, weed out irrelevant information, route critical information to SMEs to analyze, track accountability, and determine potential impact on the organization. The goal should be a regulatory change management strategy that monitors change, alerts the organization to risk conditions, and enables accountability and collaboration around changes impacting the firm. This requires a common process to deliver real-time accountability and transparency across regulatory areas with a common system of record to monitor regulatory change, measure impact, and implements appropriate risk, policy, training, and control updates. To achieve this financial services organizations must develop a process for collaboration, accountability, and integration between regulatory intelligence content providers within a GRC information and technology architecture. A well defined regulatory change management processes includes:

  • Regulatory taxonomy and repository. The foundation of regulatory change management is a regulatory taxonomy and repository. The regulatory taxonomy is a hierarchical catalog/index of regulatory areas that impact the organization. Regulations are broken into categories to logically group related areas (e.g., employment and labor, anticorruption, privacy, anti-money laundering (AML), fraud).  Integrated with this taxonomy is a repository of the regulations indexed into the taxonomy. One regulation may have multiple links into the taxonomy at different areas. The taxonomy and repository maps into the following elements:
    • Regulatory bodies (e.g., lawmakers, central banks, government bodies, regulators, self-regulatory organizations (SROs), exchanges, clearers, industry associations, trade bodies)
    • Document types (e.g., laws, regulations, rules, guidance, releases)
    • Sources (e.g., websites, RSS feeds, newsletters, etc.)
    • Attributes needed for classification, filtering, and reporting (e.g., business process, jurisdiction/geography, related regulations, regulator, status of change, relevant dates, consequences)
    • Rules & regulatory events
  • Regulatory roles and responsibilities. Success in regulatory change management requires accountability—making sure the right information gets to the right person that has the knowledge of the regulation and its impact on the organization. This requires the identification of SMEs for each regulatory category defined in the taxonomy. This can be subdivided into SMEs with particular expertise in subcategories or specific jurisdictions, or who perform specific actions as part of a series of changes to address change requirements.
  • Regulatory content feeds. To support the process of regulatory change management, the financial services organization should identify the best sources of intelligence on regulatory developments and changes. Content feeds can come directly from the regulators as well as law firms, consultancies, newsletters, blogs by experts, and content aggregators. The best content includes the regulation itself, summary of the change, impact on typical financial services organizations, and recommendations on response with suggested actions for response. The range of regulatory change content should span new regulations, amended regulations, new legislation, regulatory guidance, news and circulars, comment letters, enforcement actions, feedback statements, and regulator speeches.
  • Standard business impact analysis methodology. To maintain consistency in evaluating regulatory change, financial services organizations should have a standardized impact analysis process that measures impact of the change on the organization to determine if action is needed and prioritize action items and resources. This includes identifying related policies, controls, procedures, training, tests, assessments, and reporting that need to be reviewed and potentially revised in the context of the change. The analysis may indicate a response to simply note that the change has no impact and the organizational controls and policies are sufficient, or it may indicate that a significant policy, training, and compliance-monitoring program must be put in place.
  • Workflow and task management. The backbone of the regulatory change management process is a system of structured accountability to intake regulatory changes from content feeds and route them to the right subject matter expert for review and analysis. This is extended by getting others involved in review and response and requires some standardized workflow and task management with escalation capabilities when items are past due. The process needs to track accountability on who is assigned what tasks; establish priorities; and determine appropriate course of action.
  • Metrics, dashboarding & reporting. To govern and report on the regulatory change management process the organization needs an ability to monitor metrics and report on the process to determine process adherence, risk/performance indicators, and issues. This should provide the organization a quick view into what regulations have changed, which individuals in the organization are responsible for triage and/or impact analysis, the state of review of change, who is accountable, and overall risk impact on the organization.

Types-of-Metrics-&-Examples

Value and Benefits of a Regulatory Change Process

When organizations develop a regulatory change process they expect to be:

  • Effective. They seek to have a greater understanding of changing regulatory requirements and their impact on the organization. To enable the organization to be proactive in gathering, organizing, assessing, prioritizing, communicating, addressing and monitoring the regulatory change. This allows the organization to demonstrate evidence of good compliance practices.
  • Efficient. To allow the organization to optimize human and financial capital resources to consistently address regulatory change and enable sustainable management of resources as the business and regulatory landscape grows.
  • Agile. Competitively enable a dynamic and changing environment as an advantage over competitors that are handicapped by the same change.  This requires the organization to understand how the regulatory environment effects the organization and its strategy and how to adapt quickly and be responsive to new developments before competitors are.

The full paper on this topic in the context of financial services can be found here.

Greatest GRC Challenges: Regulatory Change Management, Part 2

The GRC Pundit BlogPublished on2 Comments on Greatest GRC Challenges: Regulatory Change Management, Part 2

This is the second in a multi-part blog series on the greatest GRC challenges organizations face. This is part 2 on the topic of regulatory change management.  In the previous post we explored the pressure organizations are under in context of regulatory change, in this post we look at how organizations processes are broken and insufficient to manage regulatory change.  Other topics in the series will be risk change management, business change management, and 3rd party management.

Broken Process and Insufficient Resources to Manage Regulatory Change

The typical organization does not have adequate processes or resources in place to monitor regulatory change. Organizations struggle to be intelligent about regulatory developments, and fail to prioritize and revise policies, and take actionable steps to be proactive. Instead, most organizations end up fire fighting trying to keep the flames of regulatory change controlled. This handicaps the organization that operates in an environment under siege by an ever-changing regulatory and legal landscape. New regulations, pending legislation, changes to existing rules, and even enforcement actions of other organizations can have a significant impact. Organizations that GRC 20/20 has interviewed in the context of regulatory change management reference the following challenges to process and resources:

  • Insufficient headcount and subject matter expertise. Regulatory change has tripled in the past five years. The effort to identify all of the applicable changes related to laws and regulation is time consuming, and organizations are understaffed. Most have not added FTEs or changed their processes despite the continued increase in regulatory change.
  • Frequency of change and number of information sources overwhelms. The frequency of updates is challenging from the regulators themselves but then comes the flood of updates from aggregators, experts, law firms and more. Organizations often subscribe to and utilize multiple sources of regulatory intelligence  that take time to go through and process to identify what is relevant.  
  • Limited workflow and task management. Organizations rely on manual processes that lack accountability and follow-through. It’s not possible to verify who reviewed a change, what actions need to be taken, or if the task was transferred to someone else. This environment produces a lack of visibility to ongoing compliance—the organization has no idea of who is reviewing what and suffers with an inability to track what actions were taken, let alone which items are “closed.” Compliance documentation is scattered in documents, spreadsheets, and emails in different versions. 
  • Lack of an audit trail. The manual and document-centric approach to regulatory change lacks defensible audit/accountability trails that regulators require. This leads to regulator and audit issues who find there is no accountability and integrity in compliance records in who reviewed what change and what action was decided upon. The lack of an audit trail is prone to deception, individuals can fabricate or mislead about their actions to cover a trail, hide their ignorance, or otherwise get themselves out of trouble. 
  • Limited reporting. Manual and ad hoc regulatory change processes do not deliver intelligence. Analyzing and reporting across hundreds to thousands of scattered documents takes time and is prone to error. This approach lacks overall information architecture and thus has no ability to report on the number of changes, who is responsible for reviewing them, the status of business impact analysis, and courses of action. Trying to make sense of data collected in manual processes and thousands of documents and emails is a nightmare.
  • Wasted resources and spending. Silos of ad hoc regulatory change monitoring lead to wasted resources and hidden costs. Instead of determining how resources can be leveraged to efficiently and effectively manage regulatory change, the different parts of the organization go in different directions with no system of accountability and transparency. The organization ends up with inefficient, ineffective and unmanageable processes and resources, unable to respond to regulatory change. The added cost and complexity of maintaining multiple processes and systems that are insufficient to produce consistent results wastes time and resources, and creates excessive and unnecessary burdens across the organization.
  • Misaligned business and regulatory agility. Regulatory change without a common process supported by an information architecture that facilitates collaboration and accountability lacks agility. Change is frequent in organizations and coming from all directions. When information is trapped in scattered documents and emails, the organization is crippled. It lacks a full perspective of regulatory change and business intelligence. The organization is spinning so many compliance plates it struggles with inefficiency. The organization cannot adequately prioritize and tackle the most important and relevant issues to make informed decisions.
  • No accountability and structure. Ultimately, this means there is no accountability for regulatory change that is strategically coordinated and the process fails to be agile, effective, and efficient in use of resources. Accountability is critical in a regulatory change process — organizations need to know who the subject-matter experts (SMEs) are, what has changed, who change is assigned to, what the priorities are, what the risks are, what needs to been done, whether it is overdue, and the results of the change analysis.

The current situation: The typical organization has a myriad of subject matter experts doing ad hoc monitoring of regulatory change and emailing parties of interest with little or no consistent follow-up, accountability, or business impact analysis. The organization is in a resource intensive confused state of monitoring regulatory risk, enforcement actions, new regulations, and pending legislation resulting in an inability to adequately predict the readiness of the organization to meet new requirements. There is no overall strategy to gather and share regulatory change information, and decide what to do about it.  

 

Greatest GRC Challenges: Regulatory Change Management, Part 1

The GRC Pundit BlogPublished on4 Comments on Greatest GRC Challenges: Regulatory Change Management, Part 1

This is the first in a multi-part blog series on the greatest GRC challenges organizations face. The first topic is regulatory change management in which there will a few posts.  This one describes the pressure the organizations are under to manage regulatory change.  Other topics in the series will be risk change management, business change management, and 3rd party management.

Tsunami of Change Overwhelms Organizations

Change is the single greatest challenge for organizations in the context of governance, risk management, and compliance (GRC). Managing the dynamic and intricate nature of change and how it cascades in impact is driving organizations toward improving their approach to regulatory change management as a defined process and integrated part of a GRC strategy within the organization.

The challenge is the compounding effect of change. Organizations have change bearing down on them from all directions that is constant, dynamic, and disruptive. Consider the scope of change financial services organizations have to keep in sync:

  • External risk environments. External risks such as market, geo-political, societal, competitive, industry, and technological forces are constantly shifting in nature, impact, frequency, scope, and velocity. 
  • Internal business environments. Within, the organization has to stay on top of changing business environments that introduce a range of operational risks such as employees, 3rd party relationships, mergers & acquisitions, processes, strategy, and technology.
  • Regulatory environments. Regulatory environments governing organizations are a constant shifting sea of requirements at local, regional, and international levels. The turbulence of thousands of changing laws, regulations, enforcement actions, administrative decisions, rule making and more has organizations struggling to stay afloat. 

Managing change across risk, business, and regulatory environments is challenging. Each of these vortexes of change is hard to monitor and manage individually, let alone how they impact each other. Change in economic or market risks bear down on the organization as it impacts regulator oversight and requirements. Internal processes, people, and technology are impacted as well. As internal processes, systems, and employees change this impacts regulatory compliance and risk posture. Change is an intricate machine of chaotic gears and movements that make the aspects of GRC challenging in organizations (as well as organizations in several other industries). Keeping current with change and keeping the organization aligned with it is one of the greatest challenges to GRC stratgies in organizations.

Regulatory Change Overwhelming the Organization

Regulatory change is overwhelming organizations across industries. Organizations are past the point of treading water as it actively drowns in regulatory change from turbulent waves of laws, regulations, enforcement actions, administrative decisions, and more around the world. Regulatory compliance and reporting is a moving target as organizations are bombarded with thousands of new regulations and changes to existing regulations each year.  Regulatory change impacts the organization as it reacts to:

  • Frequency of change. In the past five years the number of regulatory changes has more than tripled while the typical organization has not increased staff or changed processes to manage regulatory change. According to Thompson Reuters, in 2008 there 8,704 changes to regulations impacting financial services organizations, in 2013 there were over 26,950 changes. Those are just the ones they tracked. Global organizations are often dealing with more than one-hundred and twenty-five notifications of regulatory change alerts a day.
  • Global context.  Regulatory change is not limited to one jurisdiction but is a turbulent sea of change around the world. Regulations have a global impact in the market. In Asia, GRC 20/20 finds that there is often more concern over US regulation than over regulation from Asian countries. Inconsistency across regulations from jurisdiction to jurisdiction brings complexity to regulatory compliance. 
  • Inconsistency in regulations. Managing compliance and keeping up with regulatory change, exams, and reporting requirements becomes complicated when faced with International requirements. Regulatory jurisdictions have varying approaches such as principle-based regulation (also called outcome-based regulation) popular across Europe and other countries around the world, while the United States and several other countries approach a prescriptive approach to regulation that is more akin to a checkbox list of requirements in specifically telling the firm what has to be done. The principle-based approach gives the organization flexibility with the focus on the achievement of an outcome and not the specific process that got them there.  There are conflicting challenges in privacy regulations and other laws impacting financial services organizations across jurisdictions.
  • Expansion into new markets.  It has become complex for organizations to remain in foreign markets as well as enter into new markets. The pressure to expand operations and services is significant as the organization seeks to grow revenue and be competitive while at the same time being constrained by the turbulent sea of changing regulations and requirements.
  • Focus on risk assessment.  Regulatory compliance is increasingly pushed to integrate with broader enterprise and operational risk strategies with a focus on delivering specific assessment of compliance risks. For example, FINRA regulators in the US seek to ensure that compliance officers do compliance risk assessments. The discipline of risk management is becoming a pre-requisite for compliance officer skills and ensuring that compliance has a seat at the enterprise risk management (ERM) table.
  • Hoards of regulatory information. Organizations are overwhelmed by information from legal, and regulatory updates, newsletters, websites, emails, journals, blogs, tweets, and content aggregators. Compliance and legal roles struggle to monitor a growing array of regulations, legislation, regulator findings/rulings, and enforcement actions. The volume and redundancy of information adds to the problem. Managing regulatory change requires weeding through an array of redundant change notifications and getting the right information to the right person to determine the business impact of regulatory change and appropriate response. Organizations must search for the marrow of regulatory details and transform it into actionable intelligence, which can be acted upon in a measurable and consistent manner.
  • Defensible compliance. Regulators across industries and jurisdictions are requiring that compliance is not just well documented, but is operationally effective.  Case in point, Morgan Stanley is praised by regulators as a model compliance program and is the first company in 35 years of Foreign Corrupt Practices Act (FCPA) history to not be prosecuted despite bribery and corruption in their Asian real estate business. One of the points the Securities and Exchange Commission (SEC) and Department of Justice (DoJ) referenced was Morgan Stanley’s ability to keep compliance current in the midst of regulatory change: “Morgan Stanley’s internal policies . . .were updated regularly to reflect regulatory developments and specific risks.” 

The amount of regulatory change coming at organizations is staggering. Consider an international bank headquartered in South America who embarked on a project to build a database of regulatory requirements impacting the bank globally. The detail went down to the requirement level so an individual regulation may have a few requirements to more than a thousand, d
epending on the regulation. After eighteen months and cataloging over 81,000 requirements they abandoned the project. The reason was that the content was already obsolete—so much had changed during the process of documenting they did not have the resources to maintain the volume of regulatory change.  A Tier 1 Canadian bank has expressed a similar regulatory requirement documentation project demise for the same reason.   

In the next installment we will look at “Broken Process and Insufficient Resources to Manage Regulatory Change”

What are your thoughts on the increasing pressure of regulatory change management?  Please comment and share below (no promotions or solicitations).