Posted on Leave a comment

7 Habits of a Highly Effective Privacy Compliance Program

Privacy has become a front-and-center compliance risk in organizations around the world. GDPR (Europe), CCPA (California), APP (Australia), PIPEDA (Canada), PDO (Hong Kong), PIPA (Japan), ECTA (South Africa)…the world of privacy compliance is like a bowl of alphabet soup, yet this list just highlights some of many privacy regulations bearing down on organizations.

The challenge with privacy compliance is that business is dynamic. It changes minute by minute and second by second. Personal data is pervasive across the data and processes of an organization (e.g., employee data, customer data, and sales data). You may have been on top of your privacy obligations at the end of 2019, but the organization has changed significantly over the past few weeks and now also has CCPA compliance to worry about. Processes have changed, the business has changed, employees have changed, third parties have changed, your customers have changed.

Privacy compliance management has to be continuously managed and monitored in organizations. It is not a point in time effort but one that has to be addressed in the context of continuous organizational change. Privacy compliance is about identifying and mitigating the compliance, brand, and business risks associated with processing personal data. It is about managing risks across the full lifecycle of data in an organization and its web of processes, transactions, relationships, and interactions.

Here are 7 habits of highly effective privacy compliance programs to help keep you on track:

1. Appoint . . .

[this is a guest blog by GRC 20/20’s Michael Rasmussen published on the Mitratech blog. The rest of the blog can be read at the link below]

Posted on Leave a comment

UK SMCR: Trekking Up the Mountain

The importance of stages

Climbing a mountain like Mount Everest is not done haphazardly. It takes careful planning and an organized route. It also involves breaking the trek up the mountain into stages. One does not simply run up Mount Everest. You climb a mountain like Everest too quickly . . . you die. Tackling a trek up a large mountain is broken into stages that are manageable and allow for proper recovery and review of plans before the next ascent.

The same approach is done with a significant regulation, like UK SMCR in the financial services industry. UK SMCR is a significant shift in accountability, communications, attestation, and certification of staff in a financial services organization. As with other significant regulations, financial services firms are tackling UK SMCR in stages.

Beginning your SMCR journey

The first stage of the UK SMCR trek was mapping and aligning senior management functions in the organization. This was foundational and like getting to the first base camp of the UK SMCR Everest. You cannot manage accountability and certification if you do not have the responsibility maps and roles defined.

The run up to the 9th of December 2019: SMCR implementation date

The second stage of UK SMCR climb was to . . .

[this is a guest blog by GRC 20/20’s Michael Rasmussen published on the SureCloud blog. The rest of the blog can be read at the link below]

Posted on Leave a comment

Third Party GRC vs Third Party Risk Management

Business is No Longer Brick & Mortar Walls

I was recently talking to a global manufacturer about the challenges they face in defining their organization. The challenge is that there are no more brick and mortar walls that define the organization. Their organization, like yours, is a web of third party relationships. In many areas, these relationships are further complicated as they nest themselves in other relationships in deep supply chains and subcontractors. What used to be thought of as an internal risk within the traditional brick and mortar walls of this global manufacturer is now extended across an array of relationships in the extended enterprise.

However, as we were talking, it is not just about risk management. The organization has to ensure that these extended enterprise relationships share the same values and commitments to integrity define the core organization, the global manufacturer. It also has to ensure that each of these relationships is meeting the objectives that the relationship is in place for. This gets further complicated where the organization has to not only manage the performance/objectives, risk, and compliance at the relationship level but also at the contract, facility, and/or service-level.

One financial service firm stated they cannot simply manage a service provider/outsourcer relationship at the relationship level but needs to understand the details at each contract/service-level of the relationship. They might have one relationship but have 100 contracts/service levels within that relationship. They need to manage how each contract is performing and the unique risks that each contract has.

I sat on the social accountability advisory firm for one Fortune 100 firm that was managing international labor standards across 5,000 suppliers. However, these 5,000 suppliers had an aggregate of 20,000 facilities. Social accountability cannot simply be managed at the relationship level of each supplier but had to extend into each facility servicing this global firm.

However, Organizations Focus on Third Party Risk Silos

The challenge is that many organizations approach third party risk management in isolated silos. The IT security team has their process and technology focused on security. Corporate compliance and ethics are concerned about anti-bribery and corruption and have their processes for managing this in third party relationships. Then other departments such as quality, environmental, health and safety, EST/CSR, and others have their siloed processes to govern relationships. This results in no one seeing a full spectrum of the risk and exposure in these relationships. Perhaps each area has some concerns in a relationship, but in their silo it is not a big enough concern. But if they would aggregate the concerns across silos monitoring the one relationship they should have alarms going off.

However, what is often missing, is the governance of these relationships. As organizations focus on the silos of risk they often forget to put in context how these third party relationships are delivering on the performance and objectives of the relationship.

It Is Time to Move to Third Party GRC

It is time for organizations to stop thinking about Third Party Risk Management and start doing Third Party Governance, Risk Management, and Compliance (GRC). Third Party GRC is the capability to reliably achieve objectives [GOVERNANCE] while addressing uncertainty [RISK MANAGEMENT] and act with integrity [COMPLIANCE] in and across the web of the organizations third party relationships in the extended enterprise (note: this is modified from the OCEG definition of GRC to fit Third Party GRC).

Think about it. Each relationship has a purpose. There would not be a relationship if there was no purpose for it. The organization needs processes in place to reliably achieve the objectives of the relationships – this is third party governance. Then the organization needs to manage the uncertainty in the relationship. Risk, according to ISO 31000, is the effect of uncertainty on objectives. The organization has to monitor and manage the uncertainty/risk in meeting the objectives of the relationship. Then the organization needs to ensure the integrity in the relationship, that the compliance requirements, values, and ethics are in place and aligned with the organizations.

These are three legs of one stool, and all are needed. It is more than third party risk. That only gets you a partial view. Organizations need to start thinking fo Third Party GRC in defining these programs.

Only a Few Solutions Deliver on Third Party GRC

I recently published my Third Party GRC Maturity Model. This breaks the measurement of maturity of an organization’s Third Party GRC program into 5 levels – Ad Hoc, Fragmented, Defined, Integrated, and Agile. The Ad Hoc stage is fire fighting and reactive. The Fragmented stage is manual processes at a department level. Defined is technology-enabled third party risk management at a department level. Integrated is an enterprise view of third party risk across departments. Agile is where we achieve Third Party GRC as it looks at risk and compliance in context and in balance with the objectives and performance of each relationship.

From a technology perspective, there are a lot of siloed very focused solutions that do one area of third party risk to get an organization to the Defined stage. There are a handful of solutions that can take a broad view of third party risk across departments to get an organization to the Integrated stage. There are only a few solutions on the market that can truly deliver on Agile and bring an integrated view of the objectives/performance in the context of the risk and compliance in each relationship.

Today’s business environment where the business has no boundaries and extends across an array of third parties necessitates that organizations start focusing on the Agile – Third Party GRC and not silos of third party risk management.

GRC 20/20 Third Party GRC Workshops

I will be teaching my Third Party GRC by Design workshops in the following cities in February. Registration is free but limited to those within organizations managing aspects of their third party relationships. In other words, it is not open to solution providers trying to sell products/services. Come join us . . .

Upcoming Risk Management by Design workshops are:

Upcoming Policy Management by Design workshops are:

  • Chicago, Policy Management by Design, April – details forthcoming
  • New York, Policy Management by Design, April 28th
  • London, United Kingdom, Policy Management by Design, June – details forthcoming
Posted on Leave a comment

How Mature is Governance, Risk Management & Compliance (GRC) in Your Organization?

GRC maturity has evolved over the past fifteen years since OCEG first published the GRC Capability Model and we have measured these changes along the way. In 2019 we conducted our fifth GRC Maturity Survey to determine how program design and confidence has changed. The survey has hundreds of participants from organizations of all sizes and types worldwide.

Do you know that those with integrated GRC strategies are:

  • More confident in their business, understanding of risk, and impact of risk on performance
  • The level of GRC integration has steadily increased over the past several years
  • That 93% of those with mature and integrated GRC strategies state it has met or exceeded expectations
  • The level of visibility in the business and risks has increased with those with integrated GRC strategies

Join us for this webinar, where we review the current state and changes in maturity of GRC over time. Areas addressed include:

  • The level of integration of risk, compliance and performance activities and controls
  • The degree of confidence in ability to identify and manage risks and requirements
  • The use of technology to support GRC capability
  • GRC roles and organizational structures
  • Realized benefits of integrated capability and negative effects of siloed operations
  • Changes in findings from GRC Maturity Surveys across the years

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 Organization

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]