A Strategic Approach to Third Party Management, Part 2: Designing an Integrated Architecture to Support Your Strategy

This is the second in a two-part series by Michael Rasmussen on how to take a strategic approach to effectively manage and mitigate third-party risk.

To maintain the integrity of the organization and execute on strategy, the organization has to be able to see their individual third party relationships (the tree) as well as the interconnectedness of third party relationships (the forest). Third party relationships are non-linear. They are not a simple equation of 1 + 1 = 2. They are a mesh of exponential relationship and impact in which 1 + 1 = 3 or 30 or 300. What seems like a small disruption or exposure may have a massive and cascading impact. In a linear system, effect is proportional with cause. In the non-linear world of business, third party risk is exponential. If we fail to see the interconnections of third party risk on the organization, the result is often massive to unpredictable.

The challenge is that different organizational areas are doing similar things in different ways in context of their third parties. Various departments with different responsibilities for pieces of third party oversight will communicate and interact with third parties in different ways. The chaos of these many-to-many communications is slowing down relationships in a time where they need to be more nimble and agile.

The organization needs a common process, information, and technology architecture to support third party management across organization departments that includes a vested interest in third party relationships. Third party management is enabled at an enterprise level through implemen­tation of an integrated third party man­agement architecture. This offers the adapt­ability needed as a result of the dynamic nature and geographic dispersion of the modern enterprise. The right third party management platform enables the orga­nization to effectively manage risk across extended business relationships and fa­cilitates the ability to document, commu­nicate, report, and monitor the range of assessments, documents, tasks, responsi­bilities, and action plans.

Third Party Management Process Architecture

Third party management processes are used to manage and monitor the ever-changing relationship, risk, and regulatory environments in extended business relationships. While third party processes can vary by organization and industry, the common components are . . .

Continued on the ELM Solutions Blog (The GRC Pundit is a guest blogger) . . .

[button link=”http://www.wkelmsolutions.com/blog/michael-rasmussen/strategic-approach-third-party-management-part-2-designing-integrated” color=”default”]READ MORE[/button]

Now Accepting 2015 GRC Innovation Award Nominations

2015-GRC-Innovation-Award

GRC 20/20 is accepting nominations for the 2015 GRC Innovation Awards!

It has been stated that:

Any intelligent fool can make things bigger, more complex and more violent. It takes a touch of genius – and a lot of courage to move in the opposite direction. 

A primary directive of innovation is to provide experience that is simple yet complete. Like Apple with its innovative technologies, GRC solutions must approach solutions in a way that re-architects the way it works as well as the way it interacts. The goal is simple; it is itself Simplicity. Simplicity is often equated with minimalism. Yet true simplicity is more than just absence of clutter or removal of embellishment. It’s about offering up the right context, in the right place, when needed. It’s about bringing interaction and engagement to GRC process and information. GRC solutions should be intuitive.

2015 GRC Innovation Award nominations will be accepted through July 12th (no exceptions, nomination form closes down at midnight CDT on July 12th).

NOTE: the 2015 GRC Value Award process (our other award process) will begin on August 1st. Nominations have to be in before the end of August.  Recipients will be determined by end of October with announcements in November.

To establish a proper perspective, please understand what the GRC Innovations Awards are NOT:

  • It is NOT to recognize how one product has a better feature or feature set than a competitor
  • It is NOT to recognize competitive differentiators
  • It is NOT like a comparison or endorsement of solutions overall (like a Forrester Wave of Gartner Magic Quadrant)

The GRC Innovation Awards are to recognize innovations in GRC related solutions that are revolutionizing Governance, Risk Management, and Compliance (GRC).  GRC Innovation Awards are to recognize  solutions that show something truly unique, game changing, revolutionary, and new. If what you are proposing has been in your feature set for more than 12 months – it is not new and fresh.

The 2015 GRC Innovation Awards are considered across 17 categories of GRC functional areas and from two perspectives in each.  The two perspectives awards can be submitted from are:

  • User Interface & Experience. GRC 20/20 is putting specific focus on the fact that GRC solutions do not have to be ugly and cumbersome.
  • Other Innovation. Any innovation that is not tied to user interface & experience.

The seventeen categories for submission are:

  • Audit Solutions
  • Automated / Continuous Control Management
  • Business Continuity Solutions
  • Compliance Management Solutions
  • Enterprise GRC Architecture & Platforms
  • Environmental, Health &; Safety Solutions
  • Information & Technology GRC Solutions
  • Internal Control Management Solutions
  • Issue Reporting & Case Management Solutions
  • Legal Management Solutions
  • Physical Security Solutions
  • Policy & Training Solutions
  • Quality Management Solutions
  • Reputation & Responsibility Management Solutions
  • Risk Management Solutions
  • Strategy & Performance Management Solutions
  • Third Party Management Solutions

To be innovative requires that the submission be game changing and completely unique from what the competition is doing. Any submission that is just another “me too,” or “we are better than the rest” type of submission will not cut it and will quickly go to the digital trash bin.  We want to recognize vendors that are thinking outside of the box to boldly take GRC where no solution provider has gone before.

Please submit nominations before midnight on July 12, 2015.  Nomination forms will be reviewed in July, finalists selected and deeper dives in August, with recipients selected by end of August and announced in early September.  Award recipients will be announced to vendors at the end of August so that coordinated announcements/press releases can go out in the beginning of September.

[button link=”http://grc2020test.cloudaccess.host/2015-grc-innovation-award-nomination-form/” color=”default”]NOMINATION FORM[/button]

Considerations When Purchasing Policy Management Solutions

This is the second in a series of posts on buying considerations when purchasing GRC solutions.  The GRC Pundit first looked at overall considerations when purchasing GRC solutions, and in this post he turns his focus to Policy Management Solutions.

policy-portalPolicy management is one of the hottest segments in the GRC market. This is apparent in the number of RFPs and inquiries GRC 20/20 is involved in from organizations looking for policy management platforms.

Consider that policies are critical to the organization as they establish boundaries of behavior for individuals, processes, relationships, and transactions. Policies are a critical foundation of GRC. When properly managed, communicated, and enforced policies:

  • Provide a framework of governance. Policy paints a picture of behavior, values and ethics that define the culture and expected behavior of the organization; without policy there is no consistent rules and the organization goes in every direction.
  • Identify and treat risk. The existence of a policy means a risk of has been identified and is of enough significance to have a formal policy written which details controls to manage the risk.
  • Define compliance. Policies document compliance in how the organization meets requirements and obligations from regulators, contracts, and voluntary commitments.

Policies attach a legal duty of care to the organization and cannot be approached haphazardly. Mismanagement of policies can introduce liability and exposure, and noncompliant policies can and will be used against the organization in legal and regulatory proceedings to place culpability. In this context, organizations are struggling with the following issues:

  • Policies haphazardly managed in documents, fileshares, and poorly implemented portals
  • Different departments going in different policy directions
  • Lack of centralized inventory of all organization policies
  • Need to have a defensible audit trail of all interactions with a policy and training
  • Reactive and inefficient training programs
  • Policies that do not adhere to a consistent style, template, format
  • Rogue policies that put liability and exposure on the organization
  • Out of date and inconsistent policies
  • No tracking of policy exceptions

Many organizations lack a coordinated enterprise strategy for policy development, maintenance, communication, attestation, and training. To defend itself, the organization must be able to show a detailed history of what policy was in effect, how it was communicated, who read it, who was trained on it, who attested to it, what exceptions were granted, and how policy violation and resolution was monitored and managed. An organization must establish policy it is willing to enforce — but also must clearly train and communicate policy to make sure that individuals understand what is expected of them.

With today’s complex business operations, global expansion, and the ever changing legal, regulatory and compliance environments, a well-defined policy management program is vital to enable an organization to effectively develop and maintain the policies needed to reliably achieve objectives while addressing uncertainty and act with integrity. This is why organizations are aggressively looking at policy management platforms to address this challenge.

Basic, Common & Advanced Policy Management Solutions

GRC 20/20 has developed an extensive framework of RFP requirements for policy management platforms and advises organizations on RFP development and solutions the organization should be considering. GRC 20/20 covers 144 solutions in the Policy & Training Management Segment of the GRC market.  Eighty-eight of these solutions do policy management, and forty-four do training management (the overlap if you add these together are solutions that do both). Every organization has unique requirements and expectations for policy management. GRC 20/20 has detailed over 200 requirements specific to policy and training management solutions in the GRC market. Overall, policy management solutions can be mapped into the following areas:

  • Basic Policy Management Capabilities. These solutions tend to focus on the back-end of policy management, the development, approval, maintenance of policies. Policies are typically managed as documents and imported into the system as documents or PDFs. Solutions in this area are focused on managing workflow and tasks for managing and maintaining policies. They often have some basic employee portal capabilities aimed at completing tasks such as reading policies and attestation (e.g., certification, read and understood).
  • Common Policy Management Capabilities. These solutions are more built out in feature sets that offer a broader range of capabilities. This includes a stronger user portal and experience to navigate policies, the ability to build forms related to policies and manage workflow and tasks around forms, map policies to regulations and other obligations, and move beyond treating policies as documents to import into the system and have integrated word processing capabilities. These solutions also have capabilities to manage policy exemptions/exceptions, and measure policy compliance. While the employee experience is stronger than those offering basic capabilities, it is still the back-end management of policies that is central to these solutions.
  • Advanced Policy Management Capabilities. Advanced policy management solutions have all the common attributes, but take on more advanced capabilities (note, advanced capabilities extend common capabilities and not all policy management solutions support the range of advanced capabilities). Advanced capabilities tend to put a stronger focus on the employee experience – the front-end of policy management – and not just the back-end experience. Advanced capabilities include:
    • Employee portal experience is clearly stronger offering an intuitive, interactive, personal, and social policy experience for employees. Policies are most often treated as HTML and not PDFs or word processing documents, and the display of policies allows for hyperlink pop-ups for clarification and resources as well as embedding training and other policy tools.
    • Embedded training in which the solution has a full LMS capability to deliver training within the policy portal for employees and they do not have to bounce around through hyperlinks.
    • Social and gamification, as part of the employee portal the solution picks up on social aspects of employees being able to share policies with other employees, provide feedback and interaction on policies, and implement employee avatars with badges for policy and training tasks.
    • Mobility there are dedicated tablet and phone apps offering policies to employees. In fact, GRC 20/20 has been involved in several interactions with organization looking to use tablets as policy and training kiosks for employees in retail, food and beverage, manufacturing, and logistics/transportation.
    • Integration with HR management systems to push policy to new employees or those that have changed roles in the organization.
    • Integration with other GRC modules and solutions such as incident management to map incidents to violations of policy. Or risk management to map risks to policies.
    • Advanced policy authoring and editing capabilities in which policy authoring is done in a browser interface with full redlining, commenting, and editing capabilities.
    • Regulatory change management in which not just documents but chapter and verse of policies is mapped to chapter and verse of regulations and there are clearly defined processes to manage policies in the context of regulatory change.
    • Federated policy management that allows large distributed and diversified organizations to have layers of policy management committees and groups to govern complex policy lifecycles.

These summaries of basic, common, and advanced capabilities are some attributes these areas from GRC 20/20’s broader RFP requirements and analysis of policy management solutions. Organizations need to select what best fits there needs. More advanced capabilities often comes at a more significant cost of the policy management solution.

The most significant trend GRC 20/20 has seen in policy management RFPs and organizational needs is the shift of focus to the front-end of policy management.  Historically, the requirements for policy management have been largely on the back-end management and maintenance of policies with only very basic requirements in the front-end communication and attestation of policies.

Over the past three years there has been a growing trend to put equal or more importance on the front-end communication and access of policies. This is in response to organizations desiring to create a single portal for all organization policies, engage employees, and provide defensible audit trails and compliance records.  One organization even requested that the policy portal have a capability to have a green light in a corner if the policy subject matter expert is at their desk and pop-up a box to ask them a question (they used a direct analogy to online shopping with a ‘can we help you’). The overall trend is that organizations desire an engaging policy portal for employees as much as they do the back-end development of policies.OCEG.GRC Illustrated.Interactive Policy.2014

CASE IN POINT: I did the design and layout of the OCEG GRC Illustration: Engaging Employees With Interactive Policies. I have had several organizations specifically reference this illustration and state “this is what we want, who does this.”

 

Questions & Considerations to Ponder on Policy Management Solutions

Organizations considering policy management solutions should ask themselves the following questions to help guide them in developing requirements and engaging solution providers:

  • What are my back-end policy lifecycle management requirements?
  • What are my front-end policy portal and employee experience requirements?
  • Is the front-end portal as important as the back-end?
  • Do we want to develop policies in standard word processors and import them as documents/PDFs into the solution to manage?
  • Do we want to develop policies within the solution/browser interface?
  • Do we need to map policies to hotline reports, issues/incidents, controls, or risks?
  • What are our requirements for regulatory change management in context of keeping policies current?
  • What are our requirements for having a full audit and compliance trail of all interactions between policies and employees?
  • Do we desire an integrated LMS capability to manage policies and training as a collective whole in an integrated portal?
  • Do we need the capability to manage policy related forms and manage those forms through workflow and tasks for review and approval/disapproval (e.g., gifts and entertainment, conflict of interest, medical leave, political contributions)?
  • What are out mobility requirements for policy and training on tablets and smartphones?
  • Do we need to integrate with HR management systems to automate the communication of policies to new employees and those that have changed roles?
  • Do we need features of socialization and gamificaiton on the policy portal?
  • What are our internationalization and language requirements for both the back-end management of policies and the front-end policy portal?
  • What are our requirements to track and manage policy exceptions and exemptions?
  • Do we need a solution that can support federated policy management to address the need for multiple layers of policy committees and a complex policy lifecycle?

These are a subset of a broader set of questions that will be categorized and mapped in the forthcoming Buyers Guide: Policy Management Solutions, and are further detailed in GRC 20/20’s RFP requirements for policy management solutions. GRC 20/20 will be releasing the following research in the next several weeks:

  • Buyer’s Guide: Policy Management Solutions. The Buyer’s Guide goes into a detailed framework in how to approach purchasing policy management platforms.
  • Strategy Perspective: Policy Management by Design. The Strategy Perspective focuses on best practices in defining a policy governance committee, framework, lifecycle, and architecture (written from context of GRC 20/20’s Policy Management by Design Workshops).
  • Online directory of Policy & Training Management Solutions. The directory lists policy and training management solutions that GRC 20/20 covers in the market and is the first part of the broader GRC Directory being rolled out in stages.
  • Market Perspective: Policy & Training Management Solutions. This details the overall drivers, trends, market size, growth, and forecasting of the Policy & Training Management Market.

I have shared my thoughts on some buying considerations of policy management solutions. I would love to hear your thoughts and reaction to this as I work on publishing this series of GRC 20/20 research.

A Strategic Approach to Third Party Management, Part 1: Defining Your Strategy

This is the first in a two-part series by Michael Rasmussen on how to take a strategic approach to effectively manage and mitigate third-party risk.

The Modern Organization: An Interconnected Mess of Relationships

Traditional brick and mortar business is a thing of the past – physical buildings and conventional employees no longer define organizations. The modern organization is an interconnected mess of relationships and interactions that span traditional business boundaries. To take some liberties with the seventeenth-century English poet John Donne, “No [organization] is an island unto itself, every [organization] is a piece of the broader whole.”1

Layers of relationships go beyond traditional employees to include suppliers, vendors, outsourcers, service providers, contractors, subcontractors, consultants, temporary workers, agents, brokers, intermediaries, and more. Complexity grows as these interconnected relationships, processes and systems nest themselves in intricacy, such as deep supply chains. Today, business is interconnected in a flat world in which over half of the organization’s ‘insiders’ are no longer traditional employees.

In this context, organizations struggle to identify and govern their third party business relationships with a growing awareness that they stand in the shoes of their third parties. Risk and compliance challenges do not stop at traditional organizational boundaries. An organization can face reputation and economic disaster by establishing or maintaining the wrong business relationships, or by allowing good business relationships to sour because of weak governance of the relationship. Third party problems are the organizations’ problems that directly impact the brand and reputation while increasing exposure to risk and compliance matters. When questions of business practice, ethics, safety, quality, human rights, corruption, security, and the environment arise, the organization is held accountable, and it must ensure that third party partners behave appropriately.

The Inevitability of Failure

The fragmented governance of third party relationships through disconnected silos leads the organization to . . .

Continued on the ELM Solutions Blog (The GRC Pundit is a guest blogger) . . .

[button link=”http://www.wkelmsolutions.com/blog/michael-rasmussen/strategic-approach-third-party-management-part-1-defining-your-strategy” color=”default”]READ MORE[/button]

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

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

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

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

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.