Business is complex. Gone are the years of simplicity in business op­erations. Exponential growth and change in risk, regulations, globaliza­tion, distributed operations, processes, competitive velocity, business relation­ships, disruptive technology, technology, and business data encumbers organiza­tions of all sizes. Keeping complexity and change in sync is a significant challenge for boards and executives, as well as gov­ernance, risk-management, and compli­ance professionals (GRC) throughout the business.

GRC cannot be managed in iso­lated silos that lead to the inevitability of failure. This is what I call ‘anarchy' architecture where decentralized, dis­connected, and dis­tributed GRC processes catch the orga­nization off guard to risk and exposure. Complexity of business and intricacy and interconnectedness of GRC requires that we have an integrated approach to busi­ness systems, data, and GRC processes. However, the opposite is also a challenge: ‘monarchy' GRC architecture. In this approach the organization takes a one-size-fits-all approach to GRC and tries to implement GRC processes through a single GRC platform all are required to use. This forces the organization to adapt and manage GRC to the lowest common denominator.

The challenge for organizations is how to reconcile homogeneous GRC report­ing, risk transparency, performance anal­ysis, and compliance with an operating model that is increasingly heterogeneous as transactions, data, processes, relation­ships, mobility, and assets expand and multiply. GRC fails when risk is addressed as a system of parts that do not integrate and work as a collective whole. GRC fails when it is thought of as a single platform to manage workflow and tasks. GRC is about the interactions and relationships of cause and effect across strategy, process, transactions, information, and technol­ogy supporting the business and requires a GRC architecture approach.

In the end, GRC architecture, and particularly technology, should not get in the way of business. The primary is­sue is overhead in extensive services and technology implementation to integrate and develop massive GRC implementa­tions that end up slowing the business down and delaying value (if value is ever achieved). The problem is that by what GRC vendors call integration they really mean consolidation, replication, and re­dundancy. There is a huge gap between being functional and agile.

Organizations should aim to define a GRC architecture that effectively recon­ciles organization strategy, process, infor­mation, and technology into what I call a ‘federated' GRC architecture that enables oversight, reporting, accountability, and analytics through integration with busi­ness processes, data repositories, and en­terprise systems. Let GRC work with and throughout the business and not force parts of the business into a mold that does not fit. Allow for diversity while provid­ing integration, discipline, and consisten­cy. Note the word “centralization” is be­ing avoided. To “centralize” immediately imposes alien constructs that undermine agility. Federated GRC goes beyond functional to be agile and valuable to the business by delivering a harmonious rela­tionship of GRC and the business. GRC is to enable enterprise agility by creating dynamic interactions of GRC informa­tion, analytics, reporting, and monitoring in the context of business. Federated GRC enables agility, stimulates operational dy­namics, and, most importantly, effectively leverages rather than vainly tries to con­trol the distributed

The Challenges and Benefits of Federated GRC: An OCEG Roundtable

Rasmussen: I first used the term “feder­ated” in discussing an effective GRC capability in 2007. Today when I do an internet search “federated GRC” pulls more than 5,000 hits. But I'm curious to hear what “federated GRC” means to you. How do you explain it, and its benefits, in simple terms or with a simple analogy?

Mefford: To me, a federated approach means a holistic, integrated, and or­chestrated GRC capability—I mean a common capability with the same pur­pose, but autonomy on how to accom­plish it at a lower level. Not requiring everyone to conform to a common set of practices or technology, but every­one meeting the same overall objec­tives and guidelines. The groups must work together for a common purpose using negotiations and compromise instead of someone dictating the spe­cific direction. I see the United Na­tions as a great analogy. Autonomous individual countries that come togeth­er in an organized way to accomplish common purposes in a structured for­mat and process.

Delmar: GRC, by definition, involves bringing together governance, risk, and compliance disciplines from across what is increasingly becoming a com­plex, extended enterprise with deep interlocks to customer and supplier ecosystems. It simply isn't realistic to expect organizations to converge on a common set of processes for GRC. For example, many stakeholders bring ma­ture disciplines with valid and varied approaches to risk management, based on what they are trying to achieve, differences in risk tolerances, and the business process itself. For example, the PMO will be looking at a differ­ent set of risk factors than say, Opera­tional risk, audit, or security. A GRC program strives to converge on a com­mon risk and control framework, and perhaps a common issue and remedia­tion process, but will necessarily need to support a wide variety of individual taxonomies, processes, metrics, and workflows.

Harper: To be effective an organiza­tion needs to have a coordinated and synergistic approach to GRC, this is what federated means to me. There are multiple disciplines and processes at work within the organization's GRC infrastructure. Many of them have mature infrastructures and protocols behind them, for example internal au­dit, while others are much newer and are responses to current challenges—look at FCPA or mortgage compliance in the financial sector. Some are over­arching enterprise-wide functions like a corporate legal group and others are focused on much narrower goals such as anti-money laundering. The orga­nization will operate more efficiently, be more strategically agile, and have more effective governance if these disciplines are federated and work to­gether to minimize antagonism and duplication.

Rasmussen: What are some of the first steps an organization needs to take to establish an effective federated GRC capability?

Delmar: Building a federated capabili­ty first involves understanding what is important to the organization—what truly needs to be common to improve business performance, and what can or must remain federated, but ratio­nalized through a roll-up, in context of the organization as a whole, its stra­tegic objectives, legal obligations, and risk appetite. For example, a highly distributed organization with very distinct businesses may need to design in a broader degree of federation, than say, a global organization that is high­ly regulated and needs to establish a greater consistency and predictability in the business.

Harper: A very high-level corporate acknowledgment of the need to ex­ecute in a coordinated way. Without long-term support from the C-suite, individual priorities will dominate and coordination and sharing of in­frastructure will be stifled. If the C-suite can advocate for the idea that a federated approach will lead to greater business success, as opposed to just being overhead, the initiative will have much greater chances of success.

Mefford: Also, setting expectations and clearly establishing accountabili­ties. Moving to a federated approach often means getting rid of duplica­tion, closing gaps, and establishing the rules of engagement. When there are overlaps it is often difficult to get the groups to agree on who will con­tinue performing the actions. Some­times the organization has to deter­mine to scrap a particular process or technology if duplications exist, and that is often difficult for some people to accept.

Rasmussen: How do you federate peo­ple, processes, and technology each to support the GRC capability?

Harper: It is very hard to federate if ev­eryone is talking in different languages and there is no common frame of ref­erence. If you can identify a subset of enterprise GRC areas to develop a common set of corporate definitions, it will go a long way to facilitating future conversations on the process, risks, and controls. We focused on two core areas: risks and processes. We then went on to develop a common risk model which we use across the or­ganization. Part of the federated idea is that you can leverage the successes of one part of the organization not just to facilitate improved processes in other areas but also to demonstrate to the organization the benefits and successes of a federated GRC model. Inevitably, if a common approach is to be sought some or all of the current infrastructure will have to be re-cast or modified. Individuals and organi­zations often find supporting change challenging, especially if they see their own organization as being successful within its own responsibilities. Part of the leadership role is to see that they acquire a clear vision of the overall benefit to the organization and them­selves of this change.


Michael Rasmussen,Moderator

Chief GRC Pundit,

GRC 20/20 Research

Yo Delmar,

Vice President GRC,


Tom Harper,

EVP/General Auditor,

Federal Home Loan Bank of Chicago

Jason Mefford,


Mefford Associates


Source: OCEG.

Mefford: I think the main way is through the rules of engagement, which are often documented in a poli­cy or charter for the group responsible for the GRC activities. Showing peo­ple “what's in it for me” and why there needs to be change in the organization are important steps. If people don't understand why we are asking them to do certain things they often don't want to go along. This can be especially dif­ficult for the groups that feel as though they are losing something. If they can't see the benefit for the overall organi­zation they will just fight the change. Since many of the people involved in the GRC processes may disagree on the best way to accomplish certain ini­tiatives there has to be an agreement as to how things will be done. One of the biggest struggles is getting everyone to work together effectively. It seems like so many people are resistant to work­ing with other groups because they feel like protecting their own turf. They feel that if they work with and cooperate with other groups that they are somehow giving up some of their control and power. There has to be a designated leader and segregated roles so everyone knows their place in the process.

Delmar: Technology can really help build a foundation for federation; in fact, I'd say it can't really be done well without it. A strong GRC platform will provide a flexible, but common data model to support the definition of organization entities, and libraries of policies, risks, controls, and as­sets that everyone using applications shares. A single version of the truth combined with role-based access that permits users to see only that which they are authorized to see, the GRC technology platform consolidates and rationalizes information and process­es in ways single solutions cannot. Further, the GRC platform can reach into the technology eco-system and pull information in from business, IT, and security monitoring systems to provide a near-real time view of risk and compliance. Having information all in one place means the organiza­tion can now slice and dice informa­tion to provide analytics and true in­sights into when and how to take on risk. All of this is essential to moving up the maturity curve to GRC Intel­ligence.

Rasmussen: Here's a chicken and egg question—what comes first with feder­ated GRC capability, better communi­cation or better use of resources?

Mefford: I think communication has to come first. If people aren't able to communicate and come together first I don't think they can constructively work together to use resources better. With good communication I think it's easier to understand the resources that can be shared and agree on how we will run the GRC capability.

Harper: Communication is critical even if it is at the pilot level, but the al­most immediate consequences should be a better focus of resources towards the goals of the federated GRC—so I think they go hand in hand. The larger the organization the more critical the communication aspect, in smaller or­ganizations communication is typi­cally easier but the impact of using resources better has a much more sig­nificant impact.

Delmar: When an organization has a vision for an integrated, yet feder­ated GRC initiative, it pays to focus up front on establishing the right founda­tion by building the mission, goals, and objectives for federation collabor­atively with the right stakeholders and communicating these well. Those that strike the right balance, a balance that supports the maturity, readiness, and strategic intent of key stakeholders, —are more successful than those that don't make the conscious choice to manage GRC as a program. For some organizations, it's simply not possible to get the focus up front. It takes a series of successes to create the conta­gion—the groundswell of support—to have leadership recognize that these GRC initiatives are actually a program that requires strategic investment, in­terlock, and structure. Eventually, if federated GRC is a success, it will be driven into the operational fabric of the organization and become the life blood of superior performance.