Posted on Leave a comment

Tale of Two Futures: Blade Runner or Star Trek?

It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to Heaven, we were all going direct the other way – in short, the period was so far like the present period, that some of its noisiest authorities insisted on its being received, for good or for evil, in the superlative degree of comparison only.

Charles Dickens, A Tale of Two Cities (1859)

I love good literature and Charles Dickens is a favorite, particularly in the Christmas season. However, my thoughts right now are not on A Christmas Carol but on the haunting intro to A Tale of Two Cities. Charles Dickens’s evocative words come to mind as I think about enterprise risk management programs in organizations. We are at a nexus of paths right now that can lead to two very different outcomes for the future of the world, our organizations, and our personal lives.

My question for you: are we focused on the right risks?

The truth is that we are at a critical point in history, a point that can lead to two very different outcomes. In our age of technology advancement and knowledge will this be defined as the ‘age of wisdom?’ Or will it be seen as the ‘age of foolishness?’ The decisions we make and our organization’s make will lead us to a ‘season of light’ or a ‘season of darkness,’ either a ‘spring of hope’ or a winter of despair.’

In my keynotes and presentations, I ask the question: what is our future? 

Are we, as a global society that our organizations are part of, headed toward a Blade Runner future or a Star Trek future? In Blade Runner, you have a dark dystopia of social, ethical, and environmental disasters. In Star Trek, you see a green and prospering world where the environment and society thrive, and there is great social diversity and cooperation across galactic races.

My issue is that many of the enterprise risk management and GRC programs I interact with are limited in scope. If you look at these programs you would think that IT/information risk (e.g, cyber risk, digital risk) are the greatest concern. These are significant concerns, I am not trying to deny that. I cut my teeth in risk management in the 90’s in information security. My point of view is that IT/information risk is a great concern, but environmental risks are a GRAVE concern. And I mean that term literally. But environmental risk seems to be missing from the agenda of the organization’s enterprise risk, operational risk, integrated risk, and GRC agendas.

Look at the World Economic Forum’s Global Risks Landscape 2019. The most significant risks, and there are many, are environmental in focus. Where is this on the organization’s risk management agenda? Fortunately, we are seeing some changes here. I applaud the United Kingdom’s FCA/PRA that is now requiring banks and insurance companies, under the Senior Manager’s Regime/Certification Regime (UK SMCR), to have a senior management function defined and accountable to manage the firm’s risk from climate change.

It is disappointing that the leading analyst firms, Gartner and Forrester, do not cover environmental, health and safety risks in their IRM and GRC research. They are ostriches with their heads in the sand. Both of these firms talk about environmental risk and climate change in other parts of their organization, but it does not appear to be on the radar of their core research in IRM and GRC. Reading IRM and GRC reports from these analysts would leave one to think that environmental risk and climate change are not even on the radar and what we only need to focus on is IT/information risk. While Verdantix, in their Green Quadrant on Operational Risk, has a completely different set of solutions, with only two that appear on the Forrester reports and one on the Gartner report. Fortunately, with OCEG and GRC Capability Model, we have taken a true enterprise view of risk that includes environmental, health and safety, quality, and other risks that Gartner and Forrester do not see as part of their IRM and GRC research. How can a research organization in 2020 have a risk management strategy that does not include these areas? How can organizations themselves not be covering environmental risk in their enterprise and operational risk management programs?

CALL TO ACTION: it is time that our GRC/ERM programs include and integrate with ESG (environmental, social, governance), EHS (environmental, health and safety), CSR (corporate social responsibility), and sustainability initiatives. 

The reality is that organizations do need a true enterprise view of risk, and this view must include environmental risk and climate change impact on the business as well as health and safety risks. IT/information risk is critical, but it is time to ensure that environmental risk is on the radar as well in enterprise risk management programs. If we do not address this now our future will be Blade Runner and not Star Trek as we head to a ‘winter of despair’ and not a ‘spring of hope.’

Posted on Leave a comment

GRC 4.0 – Agile GRC in a Dynamic & Disrupted Organizaiton

Governance, risk management, and compliance (GRC) is the capability to reliably achieve objectives [GOVERNANCE] while addressing uncertainty [RISK MANAGEMENT] and act with integrity [COMPLIANCE]. The components of GRC provide the three legs of the stool that offer support and stability to the business and its operations. You take one leg away and the stool is no longer stable. It takes all three elements of governance, risk management and compliance working together to provide stability and balance for the organization.

Every organization is doing GRC, no matter what they call it. The question is, how mature is the organization’s GRC capability? Is it a reactive and disconnected process with departments going in many directions with much redundancy? Or is it mature, integrated and coordinated across the organization that aims to deliver on agility, efficiency and effectiveness of GRC-related processes in the context of organizational strategy, performance and objectives?

Organizations need a mature GRC capability that is supported by strong information and technology architecture that provides an integrated view of objectives, risks, compliance, controls, events and more. However, what confuses organizations is that they think GRC is about technology. That is putting the cart before the horse. GRC is about a capability delivered through a coordinated strategy and processes across the organization. Technology enables these processes to work together and function, but it does not define them. Too many organizations think GRC is something they purchase. GRC is not something you buy; it is something you do: GRC is the actions and activities of governance, risk management, and compliance.

There is technology for GRC and we often call this integrated or enterprise GRC platforms. However, these solutions are not GRC in themselves. Nor is there any single technology solution that does everything GRC. There can and should be a central core GRC platform that connects the fabric of governance, risk management and compliance processes, information and other technologies together across the organization. This architecture is the hub of GRC management and requires that it be able to integrate and connect with a variety of different systems and enterprise applications to deliver on GRC.

In my previous article, From GRC 1.0 to GRC 5.0: A History of Technology for GRC, I outlined the history of technology for GRC. From GRC 1.0 to the present of GRC 4.0 – Agile GRC, to the future of GRC 5.0 – Cognitive GRC. Today we focus on the present, what is GRC 4.0 – Agile GRC?

First to note that Agile GRC is not just about an enterprise/integrated GRC platform. Agile GRC is about the broader GRC architecture and encompasses many focused and deep solutions that do things like policy management, third party risk management, audit management, regulatory change management, and more. There are 20 segments to the GRC technology market that I have defined (which are at the bottom of this article). It is critical to understand that what is Agile GRC applies to the breadth of these segments and not just to a centralized all-encompassing platform that tries to promise to do everything and may do some things well, but often does other things only mediocre or not at all. This brings in where we came from in GRC 3.0 which was about GRC architecture and expansion of GRC beyond one platform to the integration of capabilities across best of breed systems when and where it makes sense.

The core concept of GRC 4.0 – Agile GRC technologies – is the capability to engage the entire organization on GRC and do so at a much lower cost of ownership of technology than we had in the past. Agile GRC is about the front office of the organization as much as it is about the back office GRC functions in the business. Frontline employees are making risk, compliance, and control decisions that impact organization strategy, objectives, and performance every day. Agile GRC is focused on bringing technology and engagement on GRC to the front office as well as the back office.

However, Agile GRC is also about new technology that has a much lower cost of ownership. Just because other analysts label someone as a ‘Leader’ in the upper right of their quadrants, does not mean that the solution is delivering value and is a modern solution. There are many solutions in the market that are struggling with underlying data architectures as well as user experiences that are going on being two decades old. This is not agile GRC software. Some put a fresh coat of paint on the user experience but have an underlying application and data architecture that is rotting with bloated code and complexity. This is not agile GRC software. It is critical to look deep under the hood and see what the solution is delivering and how it has evolved.

If the solution provider is not investing in updating the data/information architecture, the application architecture, and user experience – run away no matter what other analysts say. You do not need to be purchasing GRC software that is 20 years old under the hood (which is over 100 years old in human terms). It is expecting senior citizens to be competitive against twenty-year-old athletes. Buying old software that is not agile does not do the organization any good. Technology has changed. Established GRC solutions may still be very relevant, but it is critical to understand how they have evolved their underlying data and application architectures over the years. If the core code under the hood is 10 or more years old, you are dealing with a behemoth of age, complexity, bloat, and rot. I would argue that you should be concerned if the core code is over 5 years old. It is critical to understand how the solution has updated its application and data architecture over time.

This also leads to cost of ownership. Old GRC technology is expensive to implement, build-out, and maintain. One global financial services firm told them they are tired of having to have an army of ‘certified’ experts on staff for over $100,000/year each and any simple change takes months to get done. A LinkedIn post from last year described a legacy GRC implementation to the lyrics of the song Hotel California, that they are stuck and cannot get out. After having spent $500,000 in software license, and $2 million on implementation and build-out, three years later they are getting some basic functionality working. I have done an analysis of the RFPs I have worked on over the past three years. For every dollar you spend in software license for legacy GRC solutions that have not updated their data/information architectures, you are spending between $3 and $5 on implementation and buildout. For Agile GRC software, for every dollar you spend on software license you are spending between 50¢ to $1.50 in implementation and buildout. Organizations need to look at the total cost of ownership from software license to implementation to ongoing maintenance/management costs in making their decision for GRC software. Ironically, those that major analysts firms tend to rank as Leaders are the bloated dated software that are the most expensive to own and maintain. Not all of the ‘Leaders’ have kept their applications up to date and relevant.

Key factors of what defines an Agile GRC solution are:

  • Usable. The solution has a modern user experience. It does not look and feel like a solution that is 10 years old. It has a modern flat user experience design. It is contextually relevant to the role that the user logs in and sees the information most pertinent to them without having to dig through the solution. It has user-configurable dashboards and reports so the user can arrange the portal/experience to their needs that is easy to do by the user. It is also user-friendly for the front-office of the organization as well as the back-office of GRC functions.
  • Cost of ownership. The solution must have a low cost of ownership. From software licensing in relation to implementation and ongoing management. The solution should provide a compelling business case of value from efficiency (e.g., time saved, money saved), effectiveness (e.g., accuracy, thoroughness, more getting done, fewer things slipping), and agility (e.g., agile to a changing business, regulatory, and risk environment and responsive to identify and contain issues).
  • Configurable. The solution should not require custom coding where things break on upgrades. The solution should be highly configurable, even to the point of the ‘citizen developer’ where the average user in the business can understand how to configure, extend, and build out the system (Note: citizen development is great but comes at risks if the underlying data and process architecture are not thought out, so it also needs to be controlled). Things like visual workflow buildings, process diagraming, very visual forms and field buildout and placement are all part of this. But the key thing is if customization and coding are needed – CAUTION.
  • Scalable. The solution must be able to grow and adapt to the organization. The solution should streamline expansion to other departments and areas, be able to grow with the business, handle the breadth of data today but also in five years as the solution is expanded upon.
  • Adaptable. The solution combines the features of configurability and scalability to then become adaptable to the business. Where it is easy to configure and extend the solution. When there are mergers and acquisitions or business restructuring, this is easily mirrored in the GRC solution.
  • Integration. The solution must be able to integrate with other solutions. No solution does everything GRC, and GRC solutions also need to integrate with other business systems. The integration interfaces (e.g., APIs) should be easy to use and understand, and provide data integrity with the integration.
  • Analytics. The solution has a robust reporting, analytics, and dashboarding mechanism. Analytics is easy to configure and build out reports, scenarios, and comparisons and by the end-user.
  • Artificial intelligence/robotic process automation. The solution should be ready to evolve and move toward GRC 5.0 which is Cognitive GRC. This requires that the solution is starting to evaluate, leverage, and use artificial intelligence and robotic process automation capabilities to prepare for the future of GRC in the next couple of years. A solution that does not have an A.I. and robotic strategy is a caution.
  • Future proof. The solution should be easy to keep updated to the latest version. This particularly looks, again, at customization. If the solution requires so much customization and coding where things break on upgrades or upgrades are not even possible – run from it.

I am curious, what other data factors are important to you, the reader, for Agile GRC?

As we move to GRC 5.0 – Cognitive GRC, organizations need to ensure that their GRC 4.0 solutions have a strategy to embrace artificial intelligence and robotic process automation. Early adopters are starting to use these features today, but we are two years from these capabilities being broadly used for GRC. Cognitive GRC is where the solution

  • Learns from experience
  • Uses what is learned to draw conclusions
  • Identifies images and patterns
  • Solves difficult problem
  • Understands different languages
  • Creates new perspectives

When I look at the GRC market, I break it out into the following categories of solutions that I monitor and differentiate. Any solution in the market might just operate in one of these areas, or across several. But no one does it all. But there is a range of solutions that GRC 20/20 monitors, differentiates, and follows in our market research that span:

  • Integrated GRC Platforms. Capability to manage an integrated architecture across multiple GRC areas in a structured strategy, process, information and technology architecture. These are the hubs that bring multiple areas below together into one overall view of integrated GRC reporting across the enterprise.
  • Anti-Money Laundering/KYC, Fraud & Corruption. Capability to manage AML, KYC, bribery, corruption, and fraud in the organization.
  • Audit Management & Analytics. Capability to manage audit planning, staff, documentation, execution/fieldwork findings, reporting, and analytics.
  • Automated Continuous Control Management/Enforcement. 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 & Ethics Management. Capability to manage an overall compliance program, document and manage change to obligations, assess compliance, remediate non-compliance, and report. 
  • Environmental Management. Capability to document, monitor, assess, analyze, record, and report on environmental activities and compliance.
  • Finance GRC Management. Capability to manage the financial risks, controls, and reporting of the organization.
  • Health & Safety Management. Capability to manage, document, monitor, assess, report, and address incidents related to the health and safety of the workforce and workplace.
  • HR GRC Management. Capability to govern and manage risk and compliance in employee relationships, training, activities, and issues/incidents.
  • 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 the context of business objectives and manage IT processes,  technology, and information risk and compliance.
  • 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 manage the development, approval, distribution, communication, forms, maintenance, and records of policies, procedures and related awareness activities.
  • Quality Management. Capability to manage, assess, record, benchmark, and track activity, issues, failures, recalls, and improvement related to product and service quality.
  • Reputation & Responsibility Management. Capability to manage the sustainability, ESG, and corporate social responsibility program of the organization.
  • Risk Management & Analytics. Capability to identify, assess, measure, treat, manage, monitor, and report on risks to objectives, divisions, departments, processes, assets, and projects. 
  • Strategy & Performance Management. Capability to govern, define, and manage strategic, financial, and operational objectives and related performance and risk activities.
  • Third Party GRC Management. Capability to govern, manage, and monitor the array of 3rd party relationships in the enterprise, particularly risk and compliance challenges these relationships bring.

While these are categories/buckets of capabilities that GRC 20/20 maps solutions in the market into, the reality is that one solution can go across many of these areas, or be confined to just one area. But no one does everything that is why it is about GRC information and technology architecture.

GRC 20/20 is here to answer your questions on strategy, solutions, and technology for GRC. We are a research organization so it is our job to objectively understand and differentiate solutions in the market and the problems they solve. 

Feel free to ask an inquiry.

Posted on 1 Comment

From GRC 1.0 to GRC 5.0: A History of Technology for GRC

Governance, Risk Management and Compliance (GRC) is “a capability to reliably achieve objectives [GOVERNANCE], while addressing uncertainty [RISK MANAGEMENT], and act with integrity [COMPLIANCE].” This is the official definition of GRC as found in the OCEG GRC Capability Model and their focus on Principled Performance that has been in place for the past 15 years. I have been honored to be a key part of the development and evolution of the GRC Capability Model since this time.

GRC is something organizations do, it is not something they buy. The organization is governed, it manages risk, and it complies with obligations and boundaries. There is technology for GRC, but you do not buy GRC an organization does GRC. Technology enables GRC and makes GRC processes more efficient, effective, and agile. It frustrates me to no end when an organization asks me to come in and they tell me we just purchased GRC now can you come in and tell us how to do GRC. That is putting the cart before the horse. You have governance, risk management, and compliance processes in place today. What is working? What is not working? What do you want to change?

GRC is something that organizations have been doing long before we had an acronym for GRC. GRC has existed since the dawn of business and has been a part of business strategy, processes, and behavior. Whether it was working or not, GRC existed long before an acronym came into play.

But we do have an acronym, and I was the first to use that acronym on a cold snowy day in February 2002 at the Chicago office of Forrester Research (I was an analyst at Forrester from 2001 to 2007). I had just sat through a solution briefing of a technology that mapped risks to controls to policies to regulations/standards and had structured workflow and tasks for accountability and to conduct assessments. I thought this is great. When I was managing a risk and compliance consulting practice in Chicago in the 1990s this is the type of solution I envisioned and wished was available. I knew there was a market for this type of technology that took existing GRC related processes and made them efficient, effective, and agile. Throughout that day in Chicago, I noodled over it and ended up calling it GRC technology. From there I wrote the first two Forrester GRC Waves before I left Forrester in 2007 to go independent.

We talk about GRC technology it is essential to understand there is technology for GRC, but technology itself is not GRC. In fact, there is no technology solution on the planet that does all things GRC. From a strategy, process, and technology perspective there can be a core platform to document and report on objectives, performance, risks, controls, and such. But this often means that the core platform integrates with other specialized solutions as not one platform does everything related to GRC. It does not exist. One RFP that I recently supported wanted an Enterprise/Integrated GRC platform that did everything. From the top-down view of risks and controls to IT security to environmental, health and safety compliance and risks. I told them at the beginning that such a platform does not exist. They wanted to look and I wrote the RFP requirements and went through the process with them. They ended up with three platforms that did their specialized areas, with one being the master platform for overall risk reporting.

The history and evolution of GRC technology has evolved over the years since I first defined it in 2002. We are currently in GRC 4.0 – Agile GRC and watching as it transitions into GRC 5.0 – Cognitive GRC. This is not a linear timeline but an evolution as the capabilities of underlying technology for GRC evolves. So they do overlap and while we are not at GRC 5.0 today, we see the early adoption and interest in it as the technology evolves and provides itself and will become mainstream over the next two years. The stages of technology for GRC are:

  • GRC 1.0 – SOX Captivity (2002 to 2007). When I first defined and modeled technology for GRC back in February 2002 at Forrester, I clearly defined it as a broad and integrated view of objectives and the risks, control, and policies that relate to those objectives. Unfortunately, Sarbanes Oxley hit in 2002 and the focus for the first several years of GRC was on SOX compliance and internal controls over financial reporting. It drove and advanced solutions in the market, but also kept them away from being the broader GRC solution that I originally envisioned.
  • GRC 2.0 – Enterprise/Integrated GRC (2007 to 2012). Once organizations addressed SOX, it was time for technology for GRC to get back to what I had originally defined it for – an enterprise view of business objectives and the risks, controls, policies, and issues related to those objectives. The concept of the Enterprise Integrated GRC platform gained hold that multiple departments can work off a common information and technology architecture to manage risks, control, policies, compliance, audits, assessments, and incidents. But solutions had their strengths and weaknesses, and no one could do everything. My last Forrester Wave I wrote before leaving Forrester at the end of 2007 had four different Wave graphics to show the strengths and weaknesses of a solution coming from different points of view of risk, compliance, audit, and overall.
  • GRC 3.0 – GRC Architecture (2012 to 2017). As the technology for GRC uses expanded in the organization, it became apparent that no one platform solved all the challenges related to GRC. It required integration as organizations looked to leverage best of breed risk, compliance, control solutions where they made sense but still integrate with an overall platform for risk aggregation, normalization, and reporting. There was often still a central hub for GRC management, but it no longer pretended to do everything and integration with other business systems as well as deeply focused GRC solutions was necessary. GRC also started to evolve where it was no longer just about the back office of GRC processes (what some would refer to as the second and third lines of defense), but it was also about the front lines of the organization (first line) that are making risk and compliance decisions that impact objectives every day.
  • GRC 4.0 – Agile GRC (2017 to 2021). This is our current stage of GRC technology. The need for highly configurable technology that engages the entire organization on GRC from the front office to the back office. Agile technology that is configurable without advanced certifications and knowledge, what we call citizen development (though this can get out of hand and cause issues if not monitored and controlled). Where things did not break on upgrades because of heavily customized coding. The provision of GRC interfaces that are highly intuitive and engaging that were contextually relevant and easy to navigate for the role using them. Interfaces that are highly visual and interactive. Many legacy GRC solutions try to adapt to Agile by putting a fresh coat of paint on the user interface, but the underlying data and application architecture is still fifteen to twenty years old. There is a new breed of Agile software for GRC that takes this technology to the next level of value to the organization.
  • GRC 5.0 – Cognitive GRC (2021+). We are already seeing this today, the role and impact of cognitive/artificial intelligence technologies on GRC. Things such as machine learning, natural language processing, and predictive analytics are starting to bear hold and take Agile GRC technologies to the next level. While these capabilities are making strides with some early adopters, it will be about 2021 when cognitive GRC technologies gain a greater hold in the market and have proven themselves with the early adopters.

When I look at the GRC market, I break it out into the following categories of solutions that I monitor and differentiate. Any solution in the market might just operate in one of these areas, or across several. But no one does it all. But there are a range of solutions that GRC 20/20 monitors, differentiates, and follows in our market research that span:

  • Integrated GRC Platforms. Capability to manage an integrated architecture across multiple GRC areas in a structured strategy, process, information and technology architecture. These are the hubs that bring multiple areas below together into one overall view of integrated GRC reporting across the enterprise.
  • Anti-Money Laundering/KYC, Fraud & Corruption. Capability to manage AML, KYC, bribery, corruption, and fraud in the organization.
  • Audit Management & Analytics. Capability to manage audit planning, staff, documentation, execution/fieldwork findings, reporting, and analytics..
  • Automated Continuous Control Management/Enforcement. 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 & Ethics Management. Capability to manage an overall compliance program, document and manage change to obligations, assess compliance, remediate non-compliance, and report.
  • Environmental Management. Capability to document, monitor, assess, analyze, record, and report on environmental activities and compliance.
  • Finance GRC Management. Capability to manage the financial risks, controls, and reporting of the organization.
  • Health & Safety Management. Capability to manage, document, monitor, assess, report, and address incidents related to the health and safety of the workforce and workplace.
  • HR GRC Management. Capability to govern and manage risk and compliance in employee relationships, training, activities, and issues/incidents.
  • 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 the context of business objectives and manage IT processes,  technology, and information risk and compliance.
  • 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 manage the development, approval, distribution, communication, forms, maintenance, and records of policies, procedures and related awareness activities.
  • Quality Management. Capability to manage, assess, record, benchmark, and track activity, issues, failures, recalls, and improvement related to product and service quality.
  • Reputation & Responsibility Management. Capability to manage the sustainability, ESG, and corporate social responsibility program of the organization.
  • Risk Management & Analytics. Capability to identify, assess, measure, treat, manage, monitor, and report on risks to objectives, divisions, departments, processes, assets, and projects.
  • Strategy & Performance Management. Capability to govern, define, and manage strategic, financial, and operational objectives and related performance and risk activities.
  • Third Party GRC Management. Capability to govern, manage, and monitor the array of 3rd party relationships in the enterprise, particularly risk and compliance challenges these relationships bring.

While these are categories/buckets of capabilities that GRC 20/20 maps solutions in the market into, the reality is that one solution can go across many of these areas, or be confined to just one area. But no one does everything that is why it is about GRC information and technology architecture.

GRC 20/20 is here to answer your questions on strategy, solutions, and technology for GRC. We are a research organization so it is our job to objectively understand and differentiate solutions in the market and the problems they solve. Feel free to ask an inquiry.

Posted on Leave a comment

Is Policy Management Causing More Pain than Gain?

The Policy Management Illustrated Series

  • Frustrated by policy management?
  • Having trouble finding all the policies (both authorized and unauthorized) floating around in your organization?
  • Wasting time and resources that could be well applied elsewhere to help the organization achieve its objectives and stay on track?
  • Realizing something has to change? 

In our research, we have found that many organizations fail at several key stages of policy management. Too often there is no formal guidance or requirements for the authoring and approval of policies. There is no risk-based consideration to determine which policies should be supported with training. There is no single repository for all policies with version control and linkage to related obligations, processes and controls. And on and on and on. 

In response to this problem, OCEG, in collaboration with GRC 20/20, has developed an educational series of materials and webinars discussing the challenges and the solutions for better policy management. In addition to addressing each stage of the policy management lifecycle, the series will provide context that can help attendees build the business case for better management, demonstrating the value of policies in helping the organization achieve Principled Performance.

Each webinar will be accompanied by the release of a related installment in our Policy Management Illustrated infographic collection.

Whether you are directly responsible for policies or are on a compliance, risk, HR, legal, internal audit or IT team, you will find this series both helpful and enlightening.

Check out more details and register for each webinar by clicking on the titles below.  Sign up early to reserve your spot. 

Upcoming OCEG & GRC 20/20 Webinars . . .

Upcoming Workshops by GRC 20/20 . . .

Upcoming GRC 20/20 Webinars . . .

Posted on Leave a comment

Exposing IRM for What it Really is: GRC Light

Gartner, particularly John Wheeler, is hard at work trying to convince the world that their Integrated Risk Management (IRM) is something new to replace Governance, Risk Management & Compliance. You can check out John’s latest post mischaracterizing and misleading organizations in: GRC May Keep You “Out of Trouble” ,But IRM Will Keep You “ In Business” 

The first thing to note is that every solution in Gartner’s IRM Magic Quadrant and IRM Critical Capabilities reports have been and are GRC solutions. Every one of them has been marketing GRC, most for some time. These are the same platforms that have been calling themselves GRC that Gartner is now calling IRM. 

The second thing to note is that Gartner mischaracterizes what GRC is about by pushing it solely to compliance. I have refuted this time and time again by citing the long-standing official definition of GRC found in the OCEG GRC Capability Model that GRC “is a capability to reliably achieve objectives [GOVERNANCE] while addressing uncertainty [RISK MANAGEMENT] and act with integrity [COMPLIANCE].” I went into great detail on what GRC is in my recent article ‘Navigating Chaos‘ published in Enterprise Risk magazine published by The Institute of Risk Management (the real IRM). GRC since its inception has been focused on Principled Performance with an aim for the organization to reliably achieve objectives. 

If you peel back IRM in Gartner’s reports what do you find? GRC. It is not just the same technology, but the same pillars. Though I would argue it is GRC light as Gartner misses the boat in risk areas of quality, environmental, health and safety, sustainability, corporate social responsibility, and more that impact the modern organization.
Take a look at the recent Gartner IRM MQ and the IRM Critical Capabilities. It breaks IRM into three areas:

  • Business Outcome Centric. Gartner says this is “an integration-optimization-based risk practice designed to automate the linkage among relevant insights on key corporate performance-related risks.” Interesting, this sounds like the Governance pillar in the GRC definition in the capability to reliably achieve objectives. 
  • Operation-Centric. Gartner says “resilience is an adaptability-based risk practice focused on operational and IT risks offering an agile risk program in response to and re3cover form key business disruptions.” Interesting, this sounds like the Risk Management pillar in the GRC definition with the capability to “manage uncertainty.” ISO 31000 defines risk as the effect of uncertainty on objectives. 
  • Compliance-Centric. Gartner says “compliance is a regulation-based risk practice providing evaluation and evidence in support of relevant legal and regulatory requirements.” Interesting, this even mentions Compliance but only in a limited way focused on regulations. The GRC Capability Model which is about 15 years old now, defines compliance as the “capability to act with integrity.” This is more than regulatory compliance but includes compliance to the risk boundaries of the organization (e.g., tolerance, appetite, capacity); the policies of the organization; the values, ethics, corporate social responsibility commitments of the organization; and the contractual obligations of the organization.

There you have it – IRM at its core is really GRC.

What really strikes me as interesting is that Gartner puts a lot of effort into stating there is a difference in these pillars from a technology perspective. I would agree, but Gartner’s research does not. You look at the IRM Critical Capabilities research and you have the same list of solutions in nearly identical order in each of these three areas. Same solutions on top same solutions on the bottom with very little movement between these areas. Why even break this out Gartner? From this research, you are stating that the same solutions that score high in Business Outcome also are the top for Operation Centric and Compliance Centric. Same solutions and nearly the same order in each of the three areas. It does not make sense.

But what is really ironic, is that I have been discussing this for 15 years this differentiation. My last GRC Wave I wrote at Forrester in 2007 had four Wave graphics. One for overall GRC combined, one for Governance focused on outcomes and objectives, one for Risk Management focused on operational risk, and one for Compliance. They say there is nothing new under the sun, Gartner proves this. They are just taking my approach in 2007 and using it in 2019. Just relabeling/renaming its areas. HOWEVER, if you look at the 2007 Forrester GRC Wave you will find a completely different ranking of solutions in each of the areas and not the same ranking. 

Gartner, drop the IRM facade. I don’t care if you want to call GRC IRM. You can call it ERM, ABC, XYZ. It does not matter what you want to call your category. Just stop misleading the world that saying GRC has failed when you are evaluating the same exact technology solutions that have called themselves GRC. Look at how you break out and define IRM, it maps to how GRC is defined and broken out. 

Posted on Leave a comment

Understanding Third Party GRC Maturity: Agile Stage

A haphazard department- and document-centric approach for third party GRC compounds the problem and does not solve it. It is time for organizations to step back and mature their third-party GRC approaches with a cross-functional and coordinated strategy and team to define and govern third party relationships. Organizations need to mature their third-party governance with an integrated strategy, process, and architecture to manage the ecosystem of third-party relationships with real-time information about third-party performance, risk, and compliance, as well as how it impacts the organization.
GRC 20/20 has developed the Third Party GRC Maturity Model to articulate maturity in the third-party GRC processes and provide organizations with a roadmap to support acceleration through their maturity journey.

There are five stages to the model:

  1. Ad Hoc 
  2. Fragmented 
  3. Defined 
  4. Integrated 
  5. Agile

Today we look at Stage 5, the Agile level of third-party GRC.

At the Agile Maturity stage, the organization has completely moved to an integrated approach to third-party GRC across the business that includes an understanding of risk and compliance in context of performance and objectives in third-party relationships. Consistent core third-party GRC processes span the entire organization and its geographies. The organization benefits from consistent, relevant, and harmonized processes for third-party governance with minimal overhead.

The Agile Maturity is where most organizations will find the greatest balance in . . .

[this is a guest blog authored by Michael Rasmussen of GRC 20/20 that can be found at Aravo site, follow the link below to read more]

Posted on Leave a comment

The Intersection of GRC and Policy Management

Policies matter, and policy management matters. Period.

Policies are critical governance documents for every organization. They set guardrails and parameters of acceptable and unacceptable behavior for individuals, processes, and transactions. When they are managed and enforced properly, policies guide and define corporate culture.

So, why do organizations approach and manage policies so carelessly?

Policies set a duty of care for the organization, and the wrong or mismanaged policy could expose the entire operation to liability and risk. But, I find that most organizations do not even know what policies they have in place. 

Why policies are critical to GRC

Since policies are critical governance documents of the organization, they require structured management and monitoring. They simply cannot be approached haphazardly, as many organizations do.

Changes to risks and regulations, as well as constant modifications to internal business environments, can quickly make policies out of date, misaligned, and irrelevant to the organization.

As defined by OCEG, GRC is “the integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty and act with integrity.” Dissecting this definition hints at the importance of policies in the context of GRC:

  • Policies enable . . .

[this is a guest blog authored by Michael Rasmussen of GRC 20/20 that can be found at Workiva site, follow the link below to read more]

Posted on Leave a comment

Understanding Third Party GRC Maturity: Integrated Stage

A haphazard department and document centric approach for third party GRC compounds the problem and does not solve it. It is time for organizations to step back and mature their third party GRC approaches with a cross-functional and coordinated strategy and team to define and govern third party relationships. Organizations need to mature their third party governance with an integrated strategy, process, and architecture to manage the ecosystem of third party relationships with real-time information about third party performance, risk, and compliance, as well as how it impacts the organization.

GRC 20/20 has developed the Third Party GRC Maturity Model to articulate maturity in the Third Party GRC processes and provide organizations with a roadmap to support acceleration through their maturity journey.

There are five stages to the model:

  1. Ad Hoc
  2. Fragmented
  3. Defined
  4. Integrated
  5. Agile

Today we look at Stage 4, the Integrated level of Third Party GRC

In the Integrated stage, the organization has a . . .

[this is a guest blog authored by Michael Rasmussen of GRC 20/20 that can be found at Aravo site, follow the link below to read more]

Posted on Leave a comment

The 3 Lifecycle Stages of Vendor Security Risk Management: Offboarding

How do you say goodbye to a third party?

This is the third of a three-part series on vendor risk management through the lifecycle of the relationship. Today, we focus on the offboarding monitoring process.

This is the third in a three-part guest blog series looking at risk management throughout the lifecycle of a third party relationship. Previously we looked at the onboarding process, then we explored ongoing security monitoring throughout the relationship [link to posted article], now we look at offboarding and terminating a relationship.

Goodbyes are difficult. Humans tend to avoid goodbyes. If it was a beautiful close relationship, or one that ends in frustration, anger, and tears . . . most do what they can to avoid goodbyes because they are difficult. Ironically, this is true of organizations as well.

The most neglected part of the lifecycle of a third party relationship is the goodbye. The termination of the relationship. It doesn’t matter if the relationship was very productive and served, or even exceeded, its purpose, or if the relationship soured and failed. Either scenario, organizations neglect proper offboarding and closure procedures to a relationship.

This is a critical concern in the context of information security. I have encountered in organizations network connections, VPN access, and access to systems that remain active long after the relationship was over. Even if there was no network access, or if that access was terminated, there still may be data and property of the organization that the third party has internally on file servers, physically, and can live on in archives. 

Terminating a relationship is not to be approached haphazardly at the end of a relationship but should be carefully defined in contracts and controls in the onboarding of the relationship. As relationships change overtime, such as expand services, it is also necessary to update scope, controls and responsibilities for termination throughout the relationship. The last thing an organization wants at offboarding is to look for termination provisions and notice they’re missing. 

In terminating a relationship, it is critical that an organization follow these steps . . .

[this is a guest blog authored by Michael Rasmussen of GRC 20/20 that can be found at Panorays site, follow the link below to read more]

Posted on Leave a comment

Have You Hugged Your CECO/CCO Today?

Today is the official National Compliance Officer today! This is a very challenging role in organizations and one that is in the midst of a lot of change. Below is a link to my SWOT Analysis of the CECO role on this topic. I am presenting on this next week at Converge19 as well.

Here is a link with Tom Fox on his podcast discussing my upcoming presentation on the SWOT Analysis of the CECO