Category: Blogs

Enabling an Integrated Compliance Lifecycle

Compliance Management Solutions, The GRC Pundit BlogPublished onLeave a Comment on Enabling an Integrated Compliance Lifecycle

Inevitability of Failure

Ineffective Processes to Manage Regulatory Change and Compliance

Regulatory change is overwhelming organizations across industries. Organizations are past the point of treading water as they actively drown 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, making change the single greatest challenge for organizations in the context of compliance. Each vortex of change is hard to monitor and manage individually, let alone to gain an understanding of how they impact each other.

Keeping current with regulatory change and keeping the organization’s policies and procedures up to date and linked to compliance requirements is not easy. Regulators across industries and jurisdictions are requiring that compliance is not just operationally effective, but is well documented. However, organizations often do not have adequate processes or resources in place to monitor regulatory change and maintain compliance. Organizations struggle to be proactive and intelligent about regulatory developments, failing to prioritize and revise impacted policies as needed. Instead, most organizations end up firefighting trying to keep the flames of regulatory change controlled.

Organizations that GRC 20/20 has interviewed in the context of regulatory change management reference the following challenges to processes and resources:

  • 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 content  that require time-intensive analysis in order to properly understand the potential impact on the business and determine the actions required to comply.
  • 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.
  • 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 were taken as a result, or if the task was transferred to someone else. This environment produces a lack of visibility into the status of compliance obligations—there is uncertainty regarding ownership of initial review and an inability to sufficiently track what actions were taken as a result, let alone obtain reliable information on 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 trails, which regulators require. This leads to gaps in accountability and a lack of integrity in compliance records regarding who reviewed which change and what action was taken as a result. The lack of an audit trail can be conducive 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 an overall information architecture and thus is inadequate to effectively report on the number of changes, ownership of the review process, the status of business impact analysis, and courses of action. An inability to make sense of data collected in manual processes and thousands of documents exposes the organization to significant risks.
  • 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 management 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 lacks a full perspective of regulatory change and business intelligence. As a result, the organization struggles with inefficiency and cannot adequately prioritize the most important and relevant issues in order to make informed decisions.
  • No accountability and structure. Ultimately, there is insufficient accountability for regulatory change management, and the process fails to be agile, effective, and efficient in its use of resources. The regulatory change process must install strict accountability for subject matter expert review and analysis, compliance obligation task ownership and the ongoing monitoring of outstanding tasks to ensure that compliance deadlines are met.

The bottom line: Processes for managing regulatory change often constitute a myriad of subject matter experts that monitor regulatory change on an ad-hoc basis and rely on email to communicate compliance tasks to stakeholders.  Manual processes and a lack of accountability result in an inability to adequately monitor regulatory changes and predict the readiness of the organization to meet new requirements. Compliance professionals spend significant time and resources researching the mandates they must follow and struggle to keep up with new requirements and identify how changing regulations impact existing policies. A haphazard, siloed and document-centric approach to managing regulatory change results in missed requirements, wasted time, and accelerated costs. It is time for organizations to step back and implement a structured process and technology for compliance management.

Enabling 360° Insight & Control of Third Party Relationships

The GRC Pundit Blog, Third Party Management SolutionsPublished onUpdated onLeave a Comment on Enabling 360° Insight & Control of Third Party Relationships

The Extended Enterprise Demands Attention

Organizations are no longer a self-contained entity defined by brick and mortar walls and traditional employees. The modern organisation is comprised of a mixture of third party relationships that often nest themselves in complexity such as with deep supply chains. Two decades ago the term insider was synonymous with employee, now over half of the insiders in many organisations are not employees; they are contractors, consultants, temporary workers, agents, brokers, intermediaries, suppliers, vendors, outsourcers, service providers and more.

The extended enterprise of third party relationships brings on a range of risks that the organisation has to be concerned about. Managing third party risk has risen to be a significant regulatory, contractual, and board level governance mandate. Organisations need to be fully aware of the risks in third party relationships and manage this risk throughout the lifecycle of the relationship, from on-boarding to off-boarding of a third party.

Third party risks that are of primary concern to organisations include:

  • Bribery, Corruption, & Fraud
  • Conflict Minerals
  • Corporate Social Responsibility
  • Environmental, Health & Safety
  • Information Security
  • International Labour Standards (e.g., child labour, forced labour)
  • Physical Security
  • Privacy
  • Slavery & Human Rights

These risks poise significant reputational, financial, and operational concerns. They also poise a growing burden of regulatory concern and oversight (e.g., UK Modern Slavery Act, UK Anti-Bribery Act).

As organisations confront the growing exposure in third party risks they soon realise that the scattered redundant ad hoc approaches of the past are not sustainable. Third party risk can no longer be managed by different departments doing similar things in different ways, often with a mountain of emails, documents, and spreadsheets that are out of date and cost a significant amount of employee time to keep on top of. Managing third party risk requires a structured and integrated process that is supported by an information and technology architecture that can address the range of third party risks consistently without things slipping through the cracks.

An effective third party risk management process enables . . .

The rest of this post can be found as a guest blog on the SureCloud Blog . . .

[button link=”https://www.surecloud.com/blog/enabling-360-degree-insight-control-third-party-relationships”]READ MORE[/button]

Legal at the Center of GRC Leadership and Strategy

GRC Platforms & Architecture Solutions, Legal Management Solutions, The GRC Pundit BlogPublished onLeave a Comment on Legal at the Center of GRC Leadership and Strategy

Legal Challenges in a New Era

Today’s global business environment presents a broad spectrum of economic, political, social, legal and regulatory changes, which continually increase strategic and tactical complexity, and create commensurate pressures on business performance and exponential growth of often conflicting and overlapping legal and business requirements alongside global operations. The enterprise must reliably achieve business objectives while addressing uncertainty and act with integrity – all the while remaining within mandatory legal requirements. It must also manage and maintain legal risk within the limits that the organization has established.

Legal risks include:

  • Regulatory risk: The risk associated with myriad laws, rules and regulations. It includes common regulatory risks associated with labor laws, information privacy and anticorruption, as well as risks specific to industries such as banking, pharmaceuticals, energy and utilities and health care.
  • Entity management and corporate filings risk: The risk associated with keeping the entity in good standing with governing agencies, and filing information with regulators and government agencies.
  • Litigation risk: The risk associated with ongoing, imminent and potential litigation.
  • Contract risk: The risk involved in vetting contracts and monitoring compliance with contract requirements and provisions.
  • Transaction risk: The risk associated with mergers and acquisitions, including the legal risks of the acquired organization.
  • Intellectual property (IP) risk: The risk involved with copyrights, trademarks and patent infringements, as well as leakage and/or loss of confidential corporate information.

Most organizations try to address and effectively manage legal risks, IP protection, contracts, business requirements and compliance obligations. But both internal and external stakeholder forces and events have caused the organization to increase legal risk monitoring and reporting, particularly with regard to changing laws and regulations.

The Role of the Legal Department in GRC

In many organizations, the significance of the legal department is growing. Today, the department guides the enterprise beyond putting out fires in legal matters. It is being tasked to take on a proactive role in legal risk management and preventive law, while functioning as a critical pillar in an organization’s risk management strategy. This requires that legal be

The rest of this post can be found a guest blog on Wolters Kluwer ELM Solutions Blog . . .

[button link=”http://www.wkelmsolutions.com/blog/michael-rasmussen/legal-center-grc-leadership-and-strategy?mkt_tok=eyJpIjoiWlRaaE9EZGtORGhoWVdSbSIsInQiOiJqYlpRd1V0dnd2aXB3dXVuR3BFT0R2bSthdGZrSHRBeDF2Q3FPU2NYaGI3Yk9WQlRrNVlic2VTeE5Xc016aHNJVGpISitGWUlTSWpoQm4zeUV1UG0xaEFib0xBM3I2Q1h0SG4xNTNzOU5nWT0ifQ%3D%3D”]READ MORE[/button]

Managing Change is the Greatest GRC Challenge

The GRC Pundit BlogPublished onLeave a Comment on Managing Change is the Greatest GRC Challenge

Change is the single greatest challenge for organizations in the context of governance, risk management, and compliance (GRC). Managing the dynamic and intricate web of change and how it impacts the organization is driving organizations toward improving their approach to governance, risk management, and compliance (GRC) in the context of the organization’s enterprise architecture.

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 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 and the organization. Change in risks bear down on the organization, regulator oversight and requirements increase, and all of this has a direct impact on the organization’s internal processes, people, and technology. As internal processes, systems, and employees change this impacts compliance and risk posture. Change is an intricate machine of chaotic gears and movements that make the aspects of GRC challenging in organizations. Keeping current with change and keeping the organization aligned is the most significant challenge in a GRC strategy.

Broken Process and Insufficient Resources to Manage Change

Change is overwhelming organizations across industries. Organizations are past the point of treading water as it actively drowns in organization, risk, and regulatory change. GRC alignment and reporting is a moving target as organizations are bombarded with thousands of changes. The amount of change coming at organizations is staggering.

The typical organization does not have adequate processes or resources in place to monitor change that impacts GRC. Organizations struggle to be intelligent about risk and 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 change controlled. This handicaps the organization that operates in an environment under siege by an ever-changing external and internal organization landscape. Organizations that GRC 20/20 has interviewed in the context of GRC change management reference the following challenges to process and resources:

  • Insufficient headcount and subject matter expertise. Change related to GRC areas has tripled in the past five years. The effort to identify all of the applicable regulatory, risk, and organization changes is time consuming, and organizations are understaffed. Most have not added FTEs or changed their processes despite the continued increase in change.
  • Frequency of change and number of information sources overwhelms. The frequency of GRC information sources and updates is challenging to sort through and find what is relevant and significant to the organization. Organizations often subscribe to and utilize multiple sources of GRC intelligence that take time to go through and process to identify what is relevant.
  • Limited workflow and task management. Organizations rely on manual processes dependent on documents, spreadsheets and emails 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 GRC management—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.” GRC documentation is scattered in documents, spreadsheets, and emails in different versions.
  • Lack of an audit trail. The manual and document-centric approach to GRC change lacks defensible audit/accountability trails that regulators and external auditors require. This leads to regulator and auditor issues who find there is no accountability and integrity in GRC 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 GRC 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 GRC change monitoring lead to wasted resources and hidden costs. Instead of determining how resources can be leveraged to efficiently and effectively manage 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 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 organization and GRC agility. GRC 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 change and business intelligence. The organization is spinning so many GRC 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 GRC change that is strategically coordinated and the process fails to be agile, effective, and efficient in use of resources. Accountability is critical in a 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.

Providing 360° Contextual of GRC and the Organization

Mature GRC requires an understanding of the business – its strategy, organizational structure, processes, risks, obligations, commitments, and objectives.  The goal of GRC is to enable the organization to govern the organization and manage risk and compliance in the context of business.

Achieving GRC maturity requires a GRC architecture that leverages an understanding of the organization and how it operates. GRC architecture is a process by which the organization has a structured understanding of the organization’s business, capabilities, processes and business context, and use it as a foundation to ensure that GRC processes are executable, repeatable, cost effective and in line with risk appetite. In doing so, the organization has the means to assess the efficiency of their programs and align them with the organization’s strategy. The mature GRC program will define and understand GRC as a process to translate business vision and strategy into effective enterprise-wide GRC oversight and alignment.

GRC 20/20 Resources to Assist In GRC Design & Maturity

The following research resources are available to assist organizations in GRC design and architecture choices:

Inevitability of Failure: Flawed Use of Spreadsheets in GRC

The GRC Pundit BlogPublished onUpdated onLeave a Comment on Inevitability of Failure: Flawed Use of Spreadsheets in GRC

Spreadsheets, and their associates documents and emails, are the most prevalent GRC tool used by organizations. Their use comes at a significant cost if not controlled, monitored, and used properly.

In my research, organizations utilize spreadsheets for a variety of purposes. They are used to:

  • Conduct risk, compliance, and control surveys, questionnaires, and assessments
  • Inventory policies and manage related tasks
  • Conduct investigations and remediate issues
  • Document and assess controls
  • Model and assess risk and finance
  • Report on finance or GRC
  • Manage the financial close process

I am simply scratching the surface, the use of spreadsheets is pervasive in GRC and business processes. In GRC strategies I am continuously told that the primary reason the organization is looking to improve GRC related areas is to get away from the negative impact the use of spreadsheets has on GRC.

One organization in which I wrote their GRC RFP told me that 80% of their risk, compliance, control, audit, and security FTE resource time was nothing more than spreadsheet reconcilers. They were swamped trying to reconcile and report on thousands of spreadsheets and at the end of the day found the reports filled with errors from manual reconciliation. They wanted this to flip so that 80% of their staff time was managing and improving GRC and only 20% on reconciliation and reporting.

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

One mid-sized bank that GRC 20/20 has interviewed stated that one of  their regulators told them that the use of spreadsheets for compliance, risk, and control assessments was inadequate as they did not provide the right audit trails and integrity of what was assessed, who assessed it, and control any modifications to the assessment. Anyone could come back and paint a different picture, cover up a trail, and get themselves or the organization out of trouble. They demanded that the organization have a full audit trail of assessment activity.

Or consider the JP Morgan’s London Whale incident with its associated $6 billion loss. The significant contributing factor was a spreadsheet error in the models used. Consider this excerpt from page 124 of the report:

During the review process, additional operational issues became apparent. For example, the model operated through a series of Excel spreadsheets, which had to be completed manually, by a process of copying and pasting data from one spreadsheet to another… in a January 23, 2012 e-mail to the modeler, the trader to whom the modeler reported wrote that he should “keep the pressure on our friends in Model Validation and [Quantitative Research].” There is some evidence the Model Review Group accelerated its review as a result of this pressure, and in so doing it may have been more willing to overlook the operational flaws apparent during the approval process.

As a result, regulators have been cracking down on how organizations govern models and manage model risk.

Spreadsheets, left uncontrolled, make for ineffective, inefficient, and unagile GRC processes and have some serious integrity issues that violate principles of GRC.  They are very useful tools.  I use them everyday in my business, but for managing GRC information they – left to themselves – do not meet par.

The reasons spreadsheets fail for GRC are as follows:

  • No audit trail.  By themselves, without some additional tools/solutions and significant configuration, spreadsheets do not have inherent audit trails.  You cannot go back and state that you know with a specific level of certainty that those answers were gathered from that specific individual on this date and time and represent their actual, unaltered, authenticated answer to that survey, assessment, analysis, policy attestation or audit.
  • Easy to manipulate.  It is a simple task for anybody to go back and manipulate responses to paint a rosier picture to get himself or herself, someone else, or the organization out of hot water.  Someone can easily go back and cover their trail when there is no audit trail and authentication happening that tracks changes, what those changes were, who made them, and keeps a record of all changes.
  • Slipping through the cracks.  There is no structure of required workflow and task management.  Things quickly become impossible to manage in spreadsheets and emails asking for assessments to be done, audit findings to be responded to, policy attestations to be made . . . and no one gets it done.  It ends up in the trash, junk folder, filed away, and never responded to until someone is screaming.
  • No consistency.  It is hard to make assessments, surveys, attestations, policies and other GRC related information consistent.  If a new assessment is needed – we just open up a spreadsheet and create a new assessment from scratch and fail to realize that there is another assessment asking the same people half of the same questions as our new assessment.  Further, different spreadsheets are formatted in different ways and each requires its own learning curve.
  • Compilation nightmares.  Have you ever been asked to compile reports involving hundreds or even thousands of spreadsheets?  If you are a GRC professional the odds are you have.  My research and interviews with organizations find that it often takes 80+ man-hours to compile GRC (risk/compliance/audit) reports from mountains of spreadsheets.  There is a significant amount of time needed to integrate and compile information.  Myself, I would not be interested in a job very long where 80% of my time is cut, paste, manipulate data for reports.  My interest is in analysis and managing risk and compliance not in cut and paste – that is what I did in kindergarten.
  • Compilation errors.  At the end of the day, all this work compiling and integrating hundreds to thousands of spreadsheets is inevitable failure.  Odds are there is something wrong.  That much manual reporting is bound to have serious errors.  Not malicious, but inadvertent.  It happens all the time.

This is why spreadsheets by themselves fail in GRC.  There are ways to fix this. Solutions that provide and enforce consistency and audit trails within spreadsheets. Organizations need a stronger GRC architecture that brings efficiency (both human and financial capital efficiency), effectiveness (accurate and auditable reporting), and agility (timely and relevant information when it is needed) to GRC. Spreadsheets left uncontrolled work against this not for it.

What are your thoughts and experiences with spreadsheets  in GRC processes and reporting?

If you are dealing with spreadsheets in context of internal controls over financial reporting (ICFR), SOX and PCAOB pressures on end-user computing controls, please take the GRC 20/20 research survey and find out how your concerns and approach compare with your peers . . .

[button link=”http://www.surveygizmo.com/s3/2448771/Spreadsheet-Controls”]Take Survey[/button]

Making Sense of GRC Related Technology & Solutions

The GRC Pundit BlogPublished onLeave a Comment on Making Sense of GRC Related Technology & Solutions

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

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

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

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

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

GRC projects fail when:

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

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

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

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

Spreadsheets in Financial Control Processes

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

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

[button class=”kopa-button big-button color-button” link=”http://www.surveygizmo.com/s3/2448771/Spreadsheet-Controls” target=””]TAKE SURVEY[/button]

Mistakes & Challenges in Risk Management Technologies and Strategies

Risk Management Solutions, The GRC Pundit BlogPublished onLeave a Comment on Mistakes & Challenges in Risk Management Technologies and Strategies

Risk management is pervasive throughout organizations. There are many departments that manage risk with a variety of approaches, models, needs, and views into risk. This makes enterprise and operational risk management a challenge. Organizations often fail in enterprise risk management strategies when they force everyone into one flat view of risk, they also fail when they allow different views of risk but do not consider risk normalization and aggregation as they roll-up risk into enterprise reporting.

Organizations have adopted a wide range of technologies for risk management. There are several hundred solutions in the risk management market (a segment of the GRC market). Some are broad enterprise or operational risk platforms. Some solutions can be very narrow and limiting in which different departments lose capabilities they need, while other solutions can be very broad and adaptable. There are a variety of very focused risk solutions that excel at specific areas of risk management. These include:

  • Solutions focused on specific risks. These are solutions designed to manage and assess risk deeply on a very specific risk area. Such as, commodity risk, foreign exchange risk, privacy risk, model risk, and dozens of other risk areas.
  • Solutions focused on department/function risk management needs. These are solutions that are aimed at managing risks within a common department/functional area providing a common platform that specializes in risk within that area. Such as, information security, health & safety, corporate compliance, audit, finance, treasury, and more.
  • Solutions aimed at project risk management. These are solutions that help the organization manage risk in projects.
  • Solutions aimed at finance/treasury risk management. These are solutions aimed at managing an array of financial and treasury risks such as capital, market, liquidity, and credit risks.
  • Solutions aimed at operational risk management. These are solutions aimed at managing operational risks across departments to provide an integrated view of risk across business operations.
  • Solutions aimed at enterprise risk management. These are solutions that take an integrated view of strategic, finance/treasury, and operational risks (legal and compliance risk being part of operational risk). However, many solutions that advertise themselves as enterprise risk management really are only doing operational or department risk management.
  • Tools for risk management. Then there are a range of solutions that assist in risk management, but do not fit in one of the other areas. They are tools to do surveys/questionnaires/assessments. Or they assist in modeling risk such as monte carlo tools or Bayesian modeling.

The challenge is that there is not a one-stop solution for all of an organizations risk management needs. There is no a solution provider out there that addresses every area and need of risk management across the organization. In addressing this, many organizations look to risk management/GRC platforms to provide the range of capabilities they are looking for. This is done particularly when they have enterprise or operational risk management strategies to provide an integrated view of risk across the organization. HOWEVER, organizations are frequently failing in these implementations as they encounter the following issues in risk management:

  • Failing to provide top-down and bottoms up risk perspective. This is a controversial topic in the risk community, and one that I am sure I will get hammered on by opponents on either side. There are those that see that risk is all about strategy and objectives and you should do a top-down analysis of risk that starts with strategy and objectives. The other side are approaches that see risk management as a bottoms up by identifying risk at the lowest level of operations, transactions, and processes and rolling it up. My perspective is that both are needed. Risk management has to be in context of strategy and objectives, but so often something unseen down in the weeds of processes can rear its ugly head and devastate the organization. This may often have been missed in a pure top-down strategy.
  • No multi-dimensional mapping of risk relationships and impacts. A single risk can impact the organization in different ways and have exponential impact when considered in context of other risks managed in other areas but no one sees the range of related risks. Organizations fail to map risks into different hierarchies of relationships and show a multi-dimensional view of risk, impact, and relationships as it intersects with other risk categories not in the same risk hierarchy (see my post The Titanic: an Analogy of Enterprise Risk).
  • Forcing everyone into a one-size fits all risk analysis methodology. Organizations too often select risk solutions for enterprise or operational risk management that require a one-size fits all approach to risk analysis that ends up watering down risk assessments to the lowest common denominator. Well established approaches for managing risk in areas of the organization get pushed aside and the particular specialized views and details are lost leading to greater exposure. Where health & safety may have been using bow-tie risk analysis they are not forced to use heatmaps and stoplight diagrams. The organization loses depth in risk management by selecting solutions that do not have the breadth of capabilities the organization needs.
  • Lack of risk normalization and aggregation. Organizations attempt enterprise or operational risk management by utilizing solutions that lock them into a single flat view of risk scoring and appetite that creates issues when identifying and managing localized operational threats and opportunities as everything is scaled to an enterprise view. What happens when IT security’s high risk is actually lower than finance’s low risk? Either different departments have to measure all their risks in a single context that fits the entire organization, and they lose a department level perspective that is of value. Or they measure everything at a department, function, process, or project level and fail in enterprise risk reporting as they compare apples and oranges. Very few solutions on the market offer a capability to do risk normalization and aggregation. For effective risk normalization and aggregation, risks must be assessed both qualitatively and quantitatively with standardized methodologies that allow for a view of risk at an enterprise level as well as lower localized levels.
  • Overreliance on heat maps. I have written about my frustration with heat maps for the past 13 years. They provide a false view of risk. The standard two-dimensions are likelihood and impact with the upper right being perceived as the greatest risk of high-likelihood and high-impact. This is false. What organization is having billion-dollar loss events on a regular basis? They are out of business. The greatest risk exposure often is the low likelihood and high-impact events that heat maps fail to call out properly.
  • Lack of supportive risk data. Too often I see very subjective responses to risk assessments. When asked to measure risk in dimensions of likelihood and impact (there are more but we will stick to these as it is most often seen), it is often complete guess work. The organization fails to provide a history of risk events that have materialized top be an event with loss on the organization. When assessing and modeling risk, organizations need a history to mine to see how this risk has materialized in the past within their organization and with peers to be able to objectively score dimensions of likelihood and impact.

Many of these failures in enterprise and operational risk management are the result of organizations selecting GRC and risk platforms that are inadequate for the job. They rely on Gartner and Forrester reports that have a bias toward IT risk management and score and rank risk management solutions in a way that makes no sense. Gartner often only wants to see a ½ hour video demo and sends web surveys to client references. Yet organizations of all sizes are basing their enterprise and operational risk management platform purchases on analyst reports that lack depth (Forrester Waves are very broad in scope), or lack published criteria (Gartner Magic Quadrants are what they say they are, magic as the criteria, and results, are a complete mystery).

Organizations need to start thinking about risk management architecture. Organizations are often best served to take a federated approach to risk management that allows different departments some level of autonomy and supports their department level risk management strategies but also enable a common information and technology architecture to support overall enterprise and operational risk management activities and reporting.

There is no one-stop risk management solution that does everything risk management for the entire organization. Which solution can provide the best core for enterprise and operational risk management that has the right range of risk mapping, modeling, and analytic needs for the majority of the organization. But then also needs to be able to integrate with best of breed risk solutions that offer specific functionality in areas where needed.

Whether for a department risk management need, or to manage enterprise and operational risk across the organization, risk management solutions are in demand. Recent RFP and inquiry trends that GRC 20/20 is involved with show a growing demand for integrated cross-department risk management solutions. There are several hundred solutions available in risk management with varying capabilities and approaches.  Organizations need to clearly understand the breadth and depth of their requirements, map these into risk solutions capabilities, and understand that there is no one size fits all solution for risk management no matter what solution providers may say. It has become a complex segment of the GRC market to navigate, understand, and find the solution(s) that are the perfect fit for your organization.

Organizations looking for risk management solutions and intelligence can get objective insight through:

GRC 20/20’s next Research Briefing is on How to Purchase Risk Management Solutions & Platforms. Organizations looking for risk solutions should attend to help them scope their requirements and approach the market.

AGENDA . . .

  1. Defining & Understanding Risk Management
    • Definition, Drivers, Trends & Best Practices
  2. Critical Capabilities of a Risk Management Platform
    • What Differentiates Basic, Common, & Advanced Solutions
  3. Considerations in Selection of a Risk Management Platform
    • Decision Framework & Considerations to Keep in Mind
  4. Building a Business Case for Risk Management
    • Trajectory of Value in Effectiveness, Efficiency & Agility

The GRC Pundit will help organizations . . .

  • Defineand scope the risk management market
  • Understandrisk management drivers, trends, and best practices
  • Relatethe components of what makes a risk management platform
  • Identifycore features/functionality of basic, common, and advanced risk management platforms
  • Mapcritical capabilities needed in a risk management platform
  • Predictfuture directions and capabilities for risk management
  • Scopehow to purchase risk management platforms in a decision-tree framework
  • Discernconsiderations to keep in mind as you evaluate risk management solutions

[add_single_eventon id=”3028″ show_exp_evc=”yes” open_as_popup=”yes” ]

Manage Third Party Risk Exposure in an Interconnected World

The GRC Pundit BlogPublished onLeave a Comment on Manage Third Party Risk Exposure in an Interconnected World

Realize that everything connects to everything else.
Leonardo da Vinci

The world is flat, risk is pervasive, and organizations have no boundaries. We operate in a global and interconnected world. Organizations are no longer defined by brick and mortar walls nor by employees. The term insider used to be a synonym for employee. Today, more than half of insiders in many organizations are not employees. Organizations are a complex web of vendors, suppliers, contractors, consultants, temporary workers, service providers, outsourcers, brokers, dealers, intermediaries and agents.

In this interconnected world; governance, risk management, and compliance (GRC) are no longer defined by traditional organization boundaries that no longer exist. The organization must holistically look at the web of relationships that form the organization and nest in deep supply chains and subcontractor relationships. Third party risk is the organizations risk. Their issues are your issues. Their compliance and ethics problems are your problems.

Consider the wit of Douglas Adams in this context . . .

The connections between causes and effects are often much more subtle and complex than we with our rough and ready understanding of the physical world might naturally suppose . . . Let me give you an example. If you go to an acupuncturist with a toothache, he sticks a needle instead into your thigh. Do you know why he does that . . .?
― Douglas Adams, Dirk Gently’s Holistic Detective Agency

The exposure organizations face from third party relationships is significant. These include:

  • Bribery, Corruption & Fraud
  • Business Continuity
  • Contractual
  • Financial
  • Environmental
  • Ethical
  • Geo-Political
  • Health & Safety
  • Human Rights, Trafficking & Slavery
  • Import/Export & Customs
  • Labor Standards
  • Legal
  • Privacy
  • Operational
  • Regulatory Compliance
  • Reputational
  • Sanctions
  • Security
  • Strategic
  • Sourcing

Third party regulation and legislation has been particularly active over the past few years. Consider a fraction of what is happening:

  • Bribery & Corruption. We have seen expanded and increased enforcement of the US FCPA, with a focus on effective compliance. The UK Bribery Act has been in place for a few years with enforcement happening. There also is expanding regulation globally on bribery and corruption.
  • Conflict Minerals. As part of the Dodd Frank Act, thousands of companies have gone through two years of compliance with conflict mineral requirements and reporting. US publicly traded companies have to trace tin, tantalum, tungsten, and gold to see if they come from the Democratic Republic of the Congo or nine surrounding countries known for crimes against humanity and report on this.
  • FTC Power to Sue in Data Breach. This past August the U.S. Court of Appeals for the Third Circuit affirmed in FTC v Wyndham the FTC powers to sue organizations in the event of a data breach. Given over half of insiders in many organizations are third parties and the variety of breaches that involved a third party, this is going to cause increased scrutiny and attention in third party risk management.
  • OCC Regulations of Third Party Risk Management. The OCC has significantly expanded vendor risk management requirements in financial services over the past several years, making this a board level issue. Besides a legion of banks asking me questions, I am getting regular inquiries for third party relationships of banks that are responding to the greater scrutiny of the banks they do business with.
  • PCI DSS. In version 3 of PCI DSS we have seen expanded requirements on IT vendor risk assessments in context of contractual requirements if you accept major credit cards. I fully expect this to expand further in the next version after the Target incident that exposed millions of credit cards and the doorway into the breach was a heating and air-conditioning vendor that had a connection to the Target network. A hacker breached this vendor, got into Target IT systems and compromised point of sale systems across Target.
  • U.K. Modern Slavery Act. This really surprises me as I am not seeing organizations reacting to it. This past October the Modern Slavery Act went into effect and impacts a wide range of organizations. Basically, if you supply goods or services, have any connection into the United Kingdom, such as a single employee, and do £36 million or more in revenue regardless of size of your UK operations, you need to prepare an annual Slavery and Human Trafficking statement detailing the steps it is taking to prevent slavery and human trafficking throughout its business and third party relationships (down into the depth of supply chains). The guidance given on this statement requests organizations detail:
    • Organization structure, operations, and map of supply chains
    • Policies and procedures related to slavery and human trafficking
    • Due diligence processes to prevent slavery and human trafficking
    • Risk assessment of the organization and suppliers where there is risk of slavery and human trafficking
    • Key performance indicators that the organization uses to benchmark effectiveness in preventing slavery and human trafficking
    • Training conducted with employees and third parties/suppliers in context of anti-slavery and human trafficking

These risks are complex and interconnected themselves. Third party risk cannot be managed in isolated and disconnected silos. It requires an integrated process of third party governance, risk management, and compliance throughout the lifecycle of third party relationships. However, many organizations manage third party risk in ad hoc siloed manners with different departments doing things in different ways, disconnected and redundant. These processes are usually inefficient and costly as they require significant amount of time compounded as the number of third party relationships grows in organizations.

An integrated and effective third party management process enables the organization to consistently manage the lifecycle of third party relationships across:

  1. On-boarding. Automate the process of standardizing the identification of third parties to work with and moving them through registration and on-boarding while collecting required third party information and conducting appropriate due-diligence in context of the nature of the relationship. This includes third party:
    • Identification
    • Qualification
    • Contracting
    • On-boarding
  2. Ongoing communication processes. The organization manages the ongoing periodic tasks of communications, attestations and interactions with third parties. This includes cyclical and event driven interactions with each third party on:
    • Policies
    • Training
    • Attestation
    • Self-assessments/questionnaires
    • Reporting
  3. Monitoring processes. Enable the management and automation of the array of processes to continuously monitor third party relationships over their lifecycle in the organization. This includes third party:
    • Performance monitoring
    • Risk monitoring
    • Compliance monitoring
    • Ongoing due diligence monitoring
    • Issue reporting & resolution
    • Audit & inspections
  4. Forms & approvals. Manage the development and automation of internal processes to collect and report information and route things for approval in context of third party relationships. This includes:
    • New vendor/supplier request
    • Gifts, hospitality & entertainment
    • Political & charitable contributions
    • Facilitated payments
  5. Metrics & reporting. Through a solid information architecture and reporting engine, the organization brings together the data elements of the entire lifecycle to provide end-to-end reporting and metrics on third party relationships at the relationship level, risk area, or in aggregate.
  6. Renewal or Off-boarding. Utilizing the detailed history of interactions, issues, performance, non-conformance, and evolving risk scenarios, the organization manages the processes to evaluate, maintain, and renew third party relationships. All good things must come to an end, the third party management lifecycle is concluded by managing the tasks and details many organizations neglect, or forget, in off-boarding relationships that are no longer needed.

To accomplish an integrated third party management process requires that the organization formulate an overall third party management strategy and process that spans roles and functions involved. This is supported by an integrated and consistent third party information and technology architecture to provide a holistic system of record and accountability across internal functions and third parties.

However, the market has a maze of solutions to offer organizations. GRC 20/20 current tracks and monitors over 130 third party management technology solutions and over 50 third party information/content offerings. Some of these solutions are broad and meant to support a holistic integrated third party management program while others are very function and issue specific. Navigating the maze of offerings and selecting the right elements to build a third party information and technology architecture is not a trivial task. GRC 20/20 is here to help organizations understand the range of solutions available and select the right solution(s) for each organization specific third party management strategy and process, whether this is an integrated third party management strategy as proposed, or for a specific function or issue. Organizations looking for third party management solutions and intelligence can get objective insight through:

[add_single_eventon id=”2691″ show_exp_evc=”yes” open_as_popup=”yes” ]

FCPA: Change is in the Air

The GRC Pundit BlogPublished onLeave a Comment on FCPA: Change is in the Air

The past few months have seen some interesting developments in context of the U.S. Foreign Corrupt Practices Act (FCPA). I get more questions on anti-bribery and corruption than any other compliance topic in my GRC research, these developments particularly should interest compliance professionals.

The change is not a brand new direction, but a continual evolution of focus on FCPA enforcement. In a nutshell, the US Department of Justice (DoJ) in the recent Yates Memorandum stated a renewed focus on prosecuting individuals over corporations in context of bribery and corruption. If organizations self-report wrong-doing, cooperate with investigators, and can demonstrate that they have an effective compliance the focus shifts to prosecuting the individuals and not the corporation (though in cases in which corruption is pervasive and executive management is involved this may not be the case).

The element of an organization having an effective compliance program actually comes from the DoJ recently hiring a compliance counsel to facilitate the evaluation of compliance programs to support the shift in focus.

These changes have a significant impact on legal risk and corporate liability for organizations governed by FCPA. While self-reporting and cooperation are somewhat easily understood, the grey area that many are asking about is what constitutes an effective compliance program?

The standard answer is to point to the seven elements of an effective compliance program as established in the U.S. Sentencing Commission Organizational Sentencing Guidelines. This is good and something organizations should be familiar with. At a more practical level, I would encourage organizations to look at the details of the one company that the DoJ did not prosecute and went after the individual, Mr. Peterson. This is the Morgan Stanley case in 2012.

Consider this excerpt from the press release on the DoJ website:

Morgan Stanley maintained a system of internal controls meant to ensure accountability for its assets and to prevent employees from offering, promising or paying anything of value to foreign government officials.  Morgan Stanley’s internal policies, which were updated regularly to reflect regulatory developments and specific risks, prohibited bribery and addressed corruption risks associated with the giving of gifts, business entertainment, travel, lodging, meals, charitable contributions and employment.  Morgan Stanley frequently trained its employees on its internal policies, the FCPA and other anti-corruption laws.  Between 2002 and 2008, Morgan Stanley trained various groups of Asia-based personnel on anti-corruption policies 54 times.  During the same period, Morgan Stanley trained Peterson on the FCPA seven times and reminded him to comply with the FCPA at least 35 times.  Morgan Stanley’s compliance personnel regularly monitored transactions, randomly audited particular employees, transactions and business units, and tested to identify illicit payments.  Moreover, Morgan Stanley conducted extensive due diligence on all new business partners and imposed stringent controls on payments made to business partners.

Using this real-world example of a company that was not prosecuted and was praised for having an effective compliance program, we learn that an effective compliance program has the following elements:

  • Internal controls. The organization has to have a system of internal controls to address compliance and that is maintained.
  • Policies. The organization has to have established written policies that are kept current as regulations and risk change.
  • Training. The organization has to train relevant employees on policies and how to comply.
  • Reminders/awareness. Beyond training, the organization should show that it regularly reminds individuals of their responsibilities to follow policies and comply.
  • Compliance evidence/audit trail. The organization should be ready to demonstrate how often policies are communicated, training completed, and reminders sent.
  • Compliance monitoring. The organization needs to monitor transactions and activities for improper behavior.
  • Compliance audits. The organization should provide audits of compliance.
  • 3rd party due diligence. The organization should conduct due diligence on business partner relationships.
  • 3rd party controls. The organization should impose controls on transactions and activities in context of 3rd party relationships.

These changes should have organizations evaluating their compliance programs and determining how their compliance program maps to what is understood as effective in both the USSC Organizational Sentencing Guidelines and the Morgan Stanley detail from the DoJ.

In the next few weeks, GRC 20/20 is teaching in several activities that reinforce these concepts, these include:

From Backcountry Ranger to GRC Pundit

The GRC Pundit BlogPublished on1 Comment on From Backcountry Ranger to GRC Pundit

BenjiMontanaIt is the Thanksgiving holiday here in the United States, so I thought I would make this post a little more personal. I am grateful for all of my clients, followers/subscribers, and the many I get to interact with in the range of my travels at conferences, workshops, and other events. Each and everyone of you make GRC worthwhile.

As I have often stated, GRC is something organizations do it is not something organizations buy. There is a range of technology solutions that help improve GRC processes and can make GRC more effective, efficient, and agile. But purchasing a GRC solution does not get you GRC. GRC is something every organization does. Some well, others not so well. You will not find an organization that states they lack governance, do not manage risk, and can care less about compliance. Whether the organization uses the GRC acronym, something else, or no label at all . . . all do GRC in some form or fashion. At the end of the day it is actually individuals that do GRC. We all play our part and participate in the machine of strategy and operations of the organization(s) we serve. Each of you plays a part in GRC in one or many organizations.

Oddly enough, becoming a GRC professional is not something I ever strategically planned to pursue. We often talk about organizations being on a GRC journey and it is not a particular destination. As a professional it has been a journey, one that I have enjoyed but not one that was intended.

I grew up in the Northwest corner of Montana near Glacier National Park. Montana is in my blood. I echo the words of John Steinbeck, in Travels with Charley: In Search of America, “I’m in love with Montana. For other states I have admiration, respect, recognition, even some affection. But with Montana it is love. And it’s difficult to analyze love when you’re in it.” From the age of four until I was seventeen my desire was to be a backcountry ranger. I loved, and still love, the outdoors. I spent my teenage years backpacking, rock-climbing, skiing, and doing anything outdoors. I was fascinated with all aspects of nature, ecology, botany, and the variety of animals that surrounded me. The mountains themselves beckoned to me and my heart leaps when I get to see mountains, particularly those in Northwest Montana. My middle son, one of three who is twenty-one years old, lives where I grew up. His friends often chide him as he will wake up and look at the mountains and be amazed. They will remind him he has been living there for over two years; it does not matter to him as every day mountain vistas strike his heart with a fresh flood of admiration and amazement. I understand my son.

The only thing that could move me from my pursuit of the outdoors and becoming a backcountry ranger was my greater love for the Creator of all that I loved so dearly. At age seventeen I decided to pursue theology in college to become a pastor/minister. It was my first year of college that I met a wonderful young lady and fell in love. We got married two years later while still in college, and a year later got pregnant with our first child. I was serving in ministry while still trying to finish my degree, it was not enough to support a young family. We moved to Milwaukee, Wisconsin (where my darling wife is from) and I pursued work in technology, with a focus in information risk and compliance. I worked in a manufacturing organization, then in a healthcare and life science research organization, and then led a risk and compliance consulting practice in the Chicago and Milwaukee area for several years throughout the 1990’s.

During this time, I finished my undergrad degree in business, not theology, and went on to complete a Juris Doctorate. Though my passion for theology has not changed as I have finished my coursework and am writing my thesis for a Masters in Church History. My thesis is on the influence of medieval theology on J.R.R. Tolkien (another passion of mine). My favorite theologian and philosopher from church history is Anselm (11th/12th century Archbishop of Canterbury), who stated my life’s purpose so well in his Proslogium, “One who strives to lift his mind to the contemplation of God, and seeks to understand what he believes.”

As for my professional life, I started the Milwaukee chapter of the ISSA and was appointed to serve on the International Board of Directors for the ISSA serving in several capacities, first the VP of Chapter Relations, then VP of Marketing, and finally the VP of Standards & Public Policy representing the many ISSA members on public policy matters and standards impacting information security, risk, and compliance. I was able to have some of my works published in Congressional reports as well as serve on special Congressional committees.

It just so happened that the Chicago chapter president of the ISSA, and friend, was Steve Hunt, an analyst at GiGa Information Group (note the two capital G’s in GiGa, it actually stands for Gideon Gartner and not Gigabyte, Gideon left Gartner which he established to form a new bread of analyst firm in GiGa). Steve kept throwing his client inquiries/questions on compliance and policy over the fence to me for my insight and answers. One day he said, why don’t you just come work here. So my next part of my journey started – I became an industry/market research analyst at GiGa which shortly thereafter got acquired by Forrester Research.

I guess my claim to fame, should Wikipedia or something else remember me for a few months after I am gone, is on a snowy day in February 2002 at the GiGa offices in Chicago. During my consulting years in the late 1990’s I had pondered that there had to be a better way to manage risks, policies, controls, compliance requirements, and do this in context of each other. A solution provider named Telos (with their solution Xacta), focused on government, demoed a solution to me that did just that on that snowy day in Chicago. It struck me that this is exactly what I had envisioned and was looking for in the 1990’s. I saw a great demand for this type of solution and decided that it needed its own market segment and name (little did I know that the events unfolding with Enron at that time would lead to SOX which would see this market take off very rapidly).

The question before me: what do I call this market. My next briefing after Telos was with PwC. They were reviewing the range of their services with me. They had lots of slides in their presentation categorizing their services from broad to industry specific. But three separate slides stood out to me, their Governance services, their Risk Management services, and their Compliance services.  GRC. That was it. So on a snowy day in Chicago in February 2002 I first defined and labeled a market GRC.  I went on to further define and model this market, but also have worked closely with OCEG over the years in contributing to and collaborating on the GRC Capability Model as at the end of the say GRC is something organization do, not something they buy.

Thus the GRC market was born. During my tenure at Forrester I was a VP and led their GRC research, often getting their Top Analyst award. I wrote the first two Forrester GRC Waves comparing solutions in the market, as well as the two ERM Consulting Waves comparing risk management consultants. I spent seven years at Forrester and then went on my own as an independent market research analyst under my company name, GRC 20/20 Research, LLC.

The GRC market has grown over the years and I love researching and following it. I have mapped over 700 technology solution providers into different segments of the GRC market, and have now mapped over 115 providers of GRC intelligence and content solutions with over 500 content offerings into the market as well. It is a passion of mine to understand the different solutions, what differentiates each, and to model and forecast the market.

I trust this Thanksgiving holiday is a good one for each and everyone of you. I am thankful for all of you as you make my research meaningful, and I love interacting with all of you! I would love to hear about your GRC professional journey, feel free to comment on the road you took to where you are at now . . .