Re-imagining GRC (Governance, Risk & Compliance)

Arguably many corporations today that had strong risk management capabilities will have survived this pandemic more favorably. Only time will tell.

In this article we’re going to:

• define and discuss risk management generally,
• look at Gartner’s integrated risk management (IRM) approach,
• discuss the fallacy of “fortress architectures” and why they harm effective risk management
• discuss tactical issues with the way that risk management is done today and finally
• propose an integrated platform approach.

Risk can be considered as;

1. Preventable – These are typically operational in nature and the approach is to prevent them as much as possible in occurring. Control based rules models such as compliance plays the role of identifying findings or problems that will need mitigation. IT risks for instance would largely fall within this realm
2. Strategic – These risks may range from product to commercial or financial risks. Many companies may choose to accept such risks because its a fundamental part of their DNA
3. External – Covid 19 is a good example of this. The focus here is on identification of external shocks and translating them into the impact on the organization

Successful companies according to the authors made systematic risk management an essential part of the executive level functioning of the organization rather than a compartmentalized function. As with transformations, success is very much a result of a transparency of progress – the same can be said of risk management.  For us an essential facet of this is that risks when identified should be visible and easy to analyze right across the organization rather than buried in spreadsheets, PowerPoint presentations and stand alone systems. Another key take away from this approach is that risk management is therefore very variable depending on an organization’s strategy, appetite for risk as well as scope and scale of operations. One size does not fit all in this regard. It is very unlikely one single application will satisfy the complexity of needs across organizations

For more information about this framework on risk management please see Managing risks – a new framework.

This is an acronym rich space so we have provided a table to go with this funky graphic:

• DRM Digital Risk Management
• VRM Vendor Risk Management
• BCM Business Continuity Management
• AM Audit Management
• CCO Corporate Compliance and Oversight
• ELM Enterprise Legal Management

Gartner elaborates on this further:

“Integrated risk management (IRM) is a set of practices and processes supported by a risk-aware culture and enabling technologies, that improves decision making and performance through an integrated view of how well an organization manages its unique set of risks.”

Under the Gartner definition, IRM has certain attributes:

1. Strategy: Enablement and implementation of a framework, including performance improvement through effective governance and risk ownership
2. Assessment: Identification, evaluation and prioritization of risks
3. Response: Identification and implementation of mechanisms to mitigate risk
4. Communication and reporting: Provision of the best or most appropriate means to track and inform stakeholders of an enterprise’s risk response
5. Monitoring: Identification and implementation of processes that methodically track governance objectives, risk ownership/accountability, compliance with policies and decisions that are set through the governance process, risks to those objectives and the effectiveness of risk mitigation and controls
6. Technology: Design and implementation of an IRM solution (IRMS) architecture

To understand the full scope of risk, organizations require a comprehensive view across all business units and risk and compliance functions, as well as key business partners, suppliers and outsourced entities. Developing this understanding requires risk and security leaders to address all six IRM attributes.

Source Integrated Risk Management (IRM)

Our take on this is that it’s a laudable vision, well short on execution. The majority of players in their magic quadrant come nowhere near close to supporting the breadth of functionality in their model. 

DRM (security) and VRM are almost always to be found operating in separate processes, teams and tools. This of course doesn’t mean it isn’t a worthy objective. The reality of today’s organizations though is that they suffer from what we call “fortress architectures”, the opposite in fact of the spirit of IRM.

Its important to emphasize that IRM needs to be done across the enterprise as per “a comprehensive view across all business units and risk and compliance functions, as well as key business partners, suppliers and outsourced entities”. So the big question is how? Today 70% of Agile teams are using Jira, and a large number of teams use Microsoft project and a PPM tool like Clarity or Planview. 

The ITSM crowd are probably on Service Now. GRC also has its own world – maybe you’re on Lockpath. Its fair to say that there is almost a tribal aspect to this as well as control of each tribes’ tools. We know of situations where the tribe responsible for Service Now complains bitterly to senior management if Jira Service Desk is requested by users.

Each tribe fights for their own turf. It seems to us that whilst frameworks such as IRM, ITIL4 and SAFe call more strongly for end to end integration, very little has changed at least yet, in terms of the different silos. 

The picture below says it all.  

The irony of these fortresses is that Gartner perpetuates this problem. The Magic Quadrant essentially blesses an IT segment then rates the best of breed in each. It makes it easier for CIOs to make their minds up about what to choose but it doesn’t address the right way to achieve intra organizational challenges and solutions – it simply justifies each of the fortresses.

We would argue also that it buries specific risks inside each fortress preventing visibility at the overall enterprise level. Next lets examine risk from some of the competing and very credible frameworks being used today in organizations to prove the point.

1. Project Management Risk

Every good PM keeps a RAID log and in that is a Risk register.  Risks will have typically a composite risk index – probability vs impact and also a stated risk approach strategy plus a categorization. Typically PMs keep these risks in spreadsheets or a dedicated waterfall planning application like Clarity or Planview, and surface the most important of them in a Powerpoint status report. Lots of administration for an ever-changing situation.

These risks might be exposed to the business stakeholders but rarely further than that. You can bet that in a large organization thousands of risks are identified by PMs and teams never to be reviewed by the GRC team. Yet with sky high IT budgets, IT transformation efforts surely this is simply not good enough.

2. Digital Transformation Risk

Whist many organizations still have a typical PM organization such as the above – many others are going through some form of digital transformation.  Risk plays an important role here too;

“Program risks – During planning, teams have identified program risks and impediments that could impact their ability to meet their objectives. These are resolved in a broader management context in front of the whole train. One by one, the risks are discussed and addressed with honesty and transparency, and then categorized into one of the following categories: Resolved – The teams agree that the risk is no longer a concern.
Owned – Someone on the train takes ownership of the risk since it cannot be resolved during PI planning.
Accepted – Some risks are just facts or potential problems that must be understood and accepted.
Mitigated – Teams identify a plan to reduce the impact of the risk.
Confidence vote – Once program risks have been addressed, teams vote on their confidence in meeting their team PI objectives.”

© Scaled Agile, Inc.

Its likely that a scaled Agile program has its own toolkit that stores these risks also.  Yet again how much of this is readily accessible by the GRC team?

3. Incident Management and alerting (ITIL)

Typically it’s IT operations that handle incidents and production systems.  Risk is the nature of the game.  It is often the risk of deploying new versions of apps failing that sustains an independent IT operations team. 

Change Management and Incident Management are “big” process areas in this domain.  ITIL4 the latest framework here  has its own approach to risk management eg Risk management as a general business management practice. Teams are awash in risks in IT operations. Just think about all of the alerts that ops teams receive around app performance and security. They are already being triaged by sophisticated systems such as Opsgenie into incident and problem – those underlying risks too need to find their way to a central GRC function when or if they are serious enough.

4. Business Cases

Not to be outdone, likely every business case documented and submitted for approval, will have a healthy dose of risks also documented in a Word document or PowerPoint slides.

These “strategic risks” will always exist and are typically accepted by the business with mitigation steps in place. So again lots more risks here. In fact risks are everywhere to be found, being managed separately and in silos.   Yet we know that business case risks are often based on IT risk of delivery and cost. So risks interweave in these different silos as well.

Risk management is going on in varying degrees with varying effectiveness all over most organizations. The problem is its too decentralized and inaccessible to any formal GRC group. Sadly its our contention that GRC units often recreate all these risks by simply requesting all teams to tell them what their risks are,  again. GRC teams should be able to “harvest” risks across an organization through a single platform which makes them easily accessible. There are plenty of risks to be had – but its experienced GRC professionals who can sound the alarm when they see patterns or consistent risks across the organization.

Earlier, the integrated nature of best practices GRC was discussed and further that many companies have developed “fortress architectures”.  HBR and Gartner as well as a number of well supported frameworks all advocate transparency and fundamentally better integration across traditional functional lines. But that’s very clearly not happening.  

We believe there is a better way.  Jira is an example of a platform that allows you to manage anything. If its a risk, a story, a control, a request, a sale, an “anything”, that’s configurable out of the box. We call this a low code/no code platform. Our clients use Jira for just about anything you can think of. The point though is that it can be used to deliver an integrated solution that breaks up  fortress architectures without huge custom coding. Today we know many of our clients indeed large numbers of organizations (2000+) manage risks in Jira. We’re seeing a trend to put all IT related risks in Jira already.

The approach we take is to start with a solution “blueprint” and a basic starting configuration.

As can be seen Atlassian provides a foundation as well as a marketplace of thousands of apps, which we use to create sophisticated solution blueprints see https://www.blendedperspectives.com/solutions/

This becomes a single platform to manage GRC and to replace fortress architectures as much as possible.  There are no boundaries in this solution (other than security/access) enabling GRC teams to see all risks real time as they emerge.

The full solution can be found here https://www.blendedperspectives.com/solutions/grc-governance-risk-and-compliance/ as well as discussed in more depth in our webinar Risky Business Launching a fully integrated enterprise GRC solution.

A final thought is that one of the things Covid 19 has taught us is that there are very real and dangerous risks out there which can harm us greatly.  The way we manage risk is of critical importance.  We should have total enterprise transparency on risks and get rid of fortress architectures.