Category: The GRC Pundit Blog

Business is complex and dynamic, and requires agility to stay competitive. Market leadership requires the organization be quick to respond to changing conditions – to pause means loss. Governance, risk, and compliance (GRC) processes often work against business agility. Requirements and initiatives managed across numerous silos, using manual or varying technology approaches, burden the business. The lack of a common process and technology architecture comes at a significant management cost.

Whether the enterprise uses the “GRC” acronym or not, the fact is, every organization practices GRC. There is not a single executive that will tell you that they lack corporate governance, do not manage risk, and completely ignore compliance. The truth of the matter is, GRC has been a part of business since the dawn of business.

GRC is akin to the customer/client relationship management (CRM) systems of the 1980’s. Before CRM systems and processes entered the organization, client information and relationships were still being managed. The challenge was that they were being managed in scattered silos that created inconsistent and redundant data, with no view of the entire profile of the client and its interaction with the business. CRM systems entered the picture to create a single view of customer information and interaction across business processes and roles. GRC systems and processes aim to achieve the same thing – an integrated picture of governance, risk, and compliance information and processes across the business. An integrated view of GRC requires establishment of business processes and technology architecture.

The bottom line: Organizations spend more money on risk and compliance than they should, because of inefficient GRC processes.

Organizations have relied on manual and basic technology to manage risk and compliance processes. The cost to the business of inadequate GRC approaches is significant. Some areas where organizations report significant issues and cost include:

• Excessive paper and spreadsheets.
• Limited and fragmented reporting.
• Files and documents out of sync.
• Significant spend on external auditors and consultants.

A common GRC architecture makes risk and compliance efficient and manageable. Inefficiencies, redundancy, errors, and potential risks are identified, averted, or contained. This reduces risk exposure, and enhances business agility and performance.

Organizations require an enterprise view of GRC that not only brings together silos of risk and compliance, but integrates them into a common GRC architecture.

Robust GRC systems contain multiple applications, such as risk management, policy management, audit management, and document management. The individual functionality of each GRC application is key to achieving the desired results.

A less obvious and often overlooked key to GRC success lies in the integration and consistent design of each application. GRC systems lacking a common architecture (backbone), common user interface, and consistent processes and functional behaviors seldom deliver the full value and benefits sought by the organization. In fact, use of a collection of disparate GRC applications has been repeatedly demonstrated – in real-world settings – to actually reduce visibility and increase risk.

Business requires GRC architecture with a common user experience and seamless application and data integration across GRC modules. Specifically, value and economies are achieved when the GRC suite of applications delivers a common:

• User and role-centric experience: The GRC application should meet the needs of each user accessing it, with relevant information, tasks, and processes specific to the business role.
• Business-process orientation: A GRC application needs to automate business processes through workflows and elimination of information redundancy. Consistent risk and compliance management is essential to achieving value.
• Environment focused on flexibility: A common GRC architecture not only allows for consistency, but also provides business agility in adapting GRC processes to a changing business.
• Collaborative and information-rich experience: Business requires a GRC architecture that facilitates collaboration across business roles and presents information with respect to intricate relationships and within the appropriate business context.

In summary, business today requires a common GRC architecture that is context-driven and adaptable to a dynamic and changing business environment.

Simply put, a common architecture can enable a better-performing, less costly, more flexible solution. Organizations should not assume that all software platforms labeled “GRC” deliver a common technology architecture. Some solutions are assembled without a consistent strategy – a stream of mergers and acquisition activities compounds the problem, as the organization ends up with several code bases and data models.

A software system with a common architecture has the following:

• A common user interface (screen design) for all applications.
• A common workflow engine throughout the applications.
• A common security model to protect applications and data.
• A common programming language used to build the applications.
• A common database used to run the applications.
• A common enterprise architecture (a method for describing the departments and divisions within the organization).

Not all GRC software platforms are created equal. Some are a hodge-podge of technology because of a history of mergers and acquisitions; some are rushed to market without a common application and information architecture.

Delivering value and economies in GRC requires the application is built on a common architecture. With a common GRC architecture, the organization achieves business agility, consistency, efficiency, transparency, and accountability across GRC processes.

When investigating GRC solutions, Corporate Integrity encourages you to ask your technology provider the following five questions to expose the risks of a potentially flawed architecture:

1. Which portions of the current solution did you build, and which did you buy or obtain through acquisition?
2. Which portions of the system were developed by a third-party development firm?
3. Are all consultants and trainers certified in each application module?
4. Describe how the data for each application is stored in the database(s)?
5. If you change the architecture of an application or consolidate architectures for multiple applications in the future, will you guarantee:
   
   • No loss of current features or functionality?
   • A full migration to the new architecture at no additional cost?

For the full text on this – please download my research piece: The Value of a Common Architecture for GRC Platforms. I would love to hear your thoughts, experiences, and approaches to GRC Technology. Please comment on this blog or send me an e-mail

When you think you have heard everything . . .

One of the attendees at the San Jose GRC Fundamentals, Strategy, and Technology Bootcamp today shared an interesting conversation she had.

In pursuing discussion with other organizations that have implemented GRC strategies, one told her that they actually had to get a psychologist involved. That is right – a psychologist. 

It appears that the firm had so much disagreement and pull in different directions they brought a psychologist in to help the different factions work through their issues and come to common agreement on a strategy (which actually came down to two strategies when implemented).

So in the world of the GRC EcoSystem there is a new line of professional services – GRC psychologist. Build a room full of couches.

The question before you – do you need GRC consulting or GRC counseling?

The San Jose GRC Fundamentals, Strategy, & Technology bootcamp is underway with terrific interaction. The bootcamp is comprised of implementers of large down to medium sized organizations, professional service firms, and a few technology providers.

2010 is proving to be an interesting year for the reorganization of the GRC space. It kicked off with the public announcement of the EMC/RSA acquisition of Archer Technologies. Shortly thereafter you had the announcement of the merger of BPS and Resolver.

I just passed the Certified Compliance & Ethics Professional (CCEP) exam from the Society of Corporate Compliance & Ethics (SCCE). While I meant to do this years a go – I never got around to it.

Policies are a critical component of a GRC strategy – but often the most overlooked or neglected component. It amazes me the number of companies I go into that have complete disarray and chaos in their approach to managing corporate policies and procedures.

Simply put – organizations cannot ignore policy management. Consider that:

• Policies establish the culture, value, ethics, and tone of the organization.
• Policies establish boundaries for risk taking.
• Policies define how the organization complies with regulations and requirements.

Mismanagement of policies and procedures can introduce liability to the organization as a policy or procedure can establish a duty of care. Improper policy management can be used by regulators, prosecuting/plaintiff attorneys, and others to place culpability on an organization.

The typical organization suffers with ineffective policies, management, and communication. The typical organization has:

• Policies scattered across dozens of places. The typical organization has numerous portals and binders in which policies are published. There is no single authoritative source where all policies and procedures are consolidated, maintained, and managed. There is no place where an individual can see all the policies that apply to their specific role in the organization.

• Policies bound by paper. The typical organization still suffers with having numerous printed policy manuals and has not fully embraced online publishing and access to policies and procedures.
• Policies grossly out of date. The typical organization has policies that are published at some point and time and not reviewed on a regular basis. In fact, I regularly encounter organizations that have policies that have not been reviewed in years for applicability, appropriateness, and effectiveness.
• Policies that lack an owner. The typical organization has numerous policies and procedures that lack an owner that is responsible for managing them and keeping them current.
• Policies that lack any lifecycle management. The typical organization has an ad hoc approach to writing, approving, and maintaining policies with no defined system for managing the workflow, tasks, versions, and approval process.
• Policies that do not map to exceptions or incidents. The typical organization finds that it has no established system to document and manage exceptions to policies. Further, there is a lack of a system to map incidents, issues, and investigations to policies – this helps to understand where policies are breaking down and need to be addressed.
• Policies lack adherence to a consistent style guide. The typical organization has policies scattered across the organization with no through to the consistency, style, and template as to how they are written. The language and format of policies vary significantly within organization policies and procedures.

These issues are further compounded when organizations approach technology for policy management in an ad hoc manner and begin publishing policies through various content management systems (e.g., SharePoint sites) with no process to manage consolidate, manage, and keep policies consistent.

In summary, organizations are in a complete disarray in managing corporate policies and procedures – policies are out-dated, scattered across parts of the business, and not managed consistently. The recent trend in legislation and regulatory guidance is to demonstrate training and not just attestation. Policies establish the culture, values, ethics, and duties of the corporation and its agents. Organizations that take an ad hoc approach to managing and communicating policies face significant risk to their business.

When the organization is under the microscope – having a detailed trail of what policy was in effect, how it was communicated, who read it, who was trained on it, who attested to it, what exceptions were granted, what other incidents violated the policies all can provide grounds for defending the organizations. An ad hoc ‘dust in the wind’ approach to policy management may very well expose the organization to significant liability.

To consistently manage and communicate policies organizations are turning toward defined processes, workflow, and technologies to manage the lifecycle of policies. The policy management lifecycle involves several stages from definition, approval, communication, awareness, training, attestation, maintenance, and archiving. This is supported by a technology infrastructure to manage the content and process of policy management.

In the generation of Web 2.0 and YouTube it is no longer enough to simply make policies available, organizations need to deliver training and establish that individuals understand policies and procedures. Delivering interactive policy training modules has become just as important as presenting a written policy and tracking attestations.

Over the next several weeks we will look at Effective Policy Management and Communication. We will specifically explore:

• Defining a process lifecycle for managing policies
• Establishing policy ownership and accountability
• Providing consistency in policies through consistent style and language
• Communicating policies across extended business relationships
• Tracking policies attestation and delivering effective training
• Monitoring metrics to establish effectiveness and/or issues with policies
• Relating policy management to risk, issue/case, and other GRC areas
• Using technology to manage and communicate policies

In addition to this series on policy management, Corporate Integrity is also offering a full-day workshop on the topic of Effective Policy Management and Communication.

I would love to hear your thoughts, experiences, and approaches to effective policy management.

Over the past few months we have explored together the various components of my GRC Reference Architecture. This embodies the technology end of my broader GRC EcoSystem – which to date has over 1300 technology providers, professional service firms, and content providers of GRC cataloged into the GRC market.

The components of the GRC Reference Architecture that we have looked at to date include:

1. GRC Enterprise Data Architecture and Framework,
2. GRC Enterprise Architecture Application Core, and
3. GRC Business Process/Role Specific Applications.

Today we conclude the GRC Reference Architecture series with a quick overview of the industry, geographic, and technology views of applications aimed to help manage risk and compliance and broader GRC.

There are a variety of contexts for GRC initiatives within organizations. Some are focused on putting out specific fires, dealing with particular issues, meeting a requirement, or managing a solitary risk area. Others are focused broadly on driving agility, consistency, efficiency, transparency, and accountability across a range of GRC processes. This generates the demand for both enterprise GRC applications as well as business process/role specific GRC applications. This get’s further dissected into applications that aim to help organizations achieve compliance or manage risk in other areas such as:

• Industry specific issues. There are a range of solutions on the market that help specific industry verticals with the GRC related issues they face. In my analysis of the market and catalog of vendors you have dozens of technologies aimed at managing GxP compliance in life sciences, many focused on the complexity of managing credit/market/operational risk in financial services, there are a few focused on things such as Medicare/Medicaid RAC audits, even to the point of one vendor that manages compliance for car dealerships to state car sales laws. The point is that not every risk or compliance application is focused to solve every GRC issue for every industry. There are a variety of very specific GRC solutions aimed to help solve industry specific GRC issues. Even broad cross-industry GRC technology providers may have all the bells and whistles to help with industry specific issues – but they need to know what they are up against and how to solve client issues.

• Geographic specific issues. Another way to approach the GRC market is to understand the geographic reach of a vendor. There are vendors that have a very broad GRC solution that spans industries – but they only have language support or operations in specific localities. Further, there are GRC vendors that market and sell a solution for a specific geography to deal with laws and regulations, or to manage risk, within that jurisdiction.

Putting it together . . . with the GRC Reference Architecture you are able to map a vendor to what it provides for functionality – enterprise and/or business role specific as well as industry and geographic specific solutions. These work in harmony together to define what a vendor is about. One technology solution might offer enterprise GRC capabilities in risk, policy, and audit management but really is successful at selling into the IT role. Another vendor might have a very focused solution for dealing with Medicare/Medicaid RAC audits in health care within the United states.

The final way of looking at the GRC technology landscape through the reference architecture is to understand a solution’s technical capabilities. This involves understanding the technology building blocks that makes the solution work. Specific technology capabilities include the solution’s features for:

• Content management
• Process management
• Workflow management
• Survey & assessment management
• Collaboration management
• Project & resource management
• Business intelligence
• Dash boarding & reporting
• Business rule engine
• Enterprise application support
• Enterprise integration capabilities
• Learning & training management
• Security architecture
• Identity, role, and access management
• Storage & retention architecture
• Enterprise asset management
• XML & data feed integration
• Configuration & change management
• System log management
• Records management & Retention

This concludes our high-level look at the GRC Reference Architecture. I would encourage you to review the several related newsletters and blog posts and provide feedback as I put this into a written document to be published in the next month. You may comment on my blog or send me an e-mail.

The next step, besides publishing under the Corporate Integrity name, is to integrate this into the OCEG GRC Technology Blueprint which is in revision to be finalized with these changes in the next few weeks. This is meant to be a resource in framing the variety of GRC solutions on the market today and be a guide to vendors looking for solutions to their governance, risk, and compliance problems.

Beginning next week I turn the newsletter to a new topic of looking at the disarray of policies within organizations and ways to improve policy life cycle management and management.

Happy New Year! I trust that 2010 will bring you success and direction in your personal and professional life.

First I need to state a deep thank you to all of my subscribers that have reached out to me over the past several weeks with your sympathy and prayers for my family as my father passed away. I am amazed and overwhelmed with emotion at the number of personal comforts and encouragements you have given when most of us only connect on a professional level. My father’s struggle with cancer came on suddenly at the end of May and already in June the Doctor’s only gave him two weeks to live. Two weeks turned into six months – from which we are grateful. I spent more quality time with my dad (traveling to Seattle) than I ever have – cherished memories. My clients have been great – I had to reschedule the San Jose GRC Bootcamp (I was in San Jose for it when I learned of his passing) and everyone attendee was encouraging and open to rescheduling. I have some of the greatest clients in the world!

My purpose of this newsletter is to communicate my upcoming research agenda and direction in 2010.

The GRC market in 2010 is already proving to be interesting – particularly with the EMC/RSA acquisition of Archer. I am already seeing a lot of interaction from large Fortune 1000 companies down into small to medium sized organizations to define a GRC strategy and resolve cumbersome risk and compliance processes. There will be a lot of consolidation of the market in 2010.

The greatest shift is that I am doing more training and education worskhops/bootcamps. Since first creating the GRC market (eight years back) I have been continually frustrated in the lack of good GRC training and understanding on what it is. I continue to partner with OCEG to provide the best risk, compliance, and broad GRC training available. This is being offered in three day bootcamps, as well as very topic specific workshops (e.g., policy management, risk management).

I am kicking off the New Year with my Online Workshop: 2010 GRC Drivers, Trends, & Market Directions. In this workshop I am communicating the shape, size, and direction of the GRC market as well as best practices, approaches, and trends in a two-hour online format.

As for my upcoming research agenda:

• GRC Reference Architecture. Representing the Technology end of my GRC EcoSystem, the GRC Reference Architecture will be wrapped up in blog/newsletter format this week with another newsletter coming into your inbox on the business/role specific GRC applications. I will tie all of this together in a Corporate Integrity research piece on the GRC Reference Architecture by the end of January and will incorporate this into the revised OCEG GRC IT Blueprint as well for review and approval by the OCEG Technology Council.

• Investigations Management. I have been working for the past three months on research covering investigations management platforms – the market, players, feature/functionality, and best practices in investigations management. I originally planned to publish this by the end of December but my family circumstances put this into January. This will be published in the next month as well.

• Policy Management. After I wrap up the GRC Reference Architecture newsletter this week I will begin a newsletter series on effective management and communication of policies across the organization. This ties into the full-day workshop training I am doing on this subject at the end of February. I am also working on a book on policy management in 2010.

• 3rd Party/Supply-Chain/Vendor Risk Management. In a few months I am going to take up the topic of managin risk and compliance across extended business relationships. This area has been keeping me very busy for the past two years and want to do more writing on this topic.

• Risk Management and ISO 31000. With the release of ISO 31000 I plan on doing more writing, expository, and training on risk management to align with this important standard in 2010.

• Economic Value Proposition of GRC. 2010 will also bring more focus of my research on the economic justification and reasoning for GRC processes and solutions. I am frustrated with the amount of money companies waste on manual, paper-based efforts for GRC or ones that are encumbered by email instead of workflow and spreadsheets for assessments that have no integrity, audit trail, or scalability. GRC processes and solutions make sense because they improve business agility, consistency, efficiency, transparency, and accountability.

My upcoming 2010 events (those that are planned out to date for the next few months) are as follows:

ONLINE WORKSHOP: 2010 GRC Drivers, Trends, & Market Directions

Thursday, January 14, 2010 from 11:00 AM – 1:00 PM (CT)

 

OCEG BOOTCAMP San Jose: GRC Fundamentals, Strategy, & Technology

Wednesday, January 27, 2010 at 8:00 AM – Friday, January 29, 2010 at 5:00 PM (ET) San Jose, CA | Hotel Valencia Santana Row

 

OCEG BOOTCAMP Atlanta: GRC Fundamentals, Strategy, & Technology

Wednesday, February 17, 2010 at 8:00 AM – Friday, February 19, 2010 at 5:00 PM (ET) Atlanta, GA | TWELVE Atlantic Station

 

WORKSHOP: Effective Policy Management & Communication

Wednesday, February 24, 2010 from 8:00 AM – 5:00 AM (CT) Delafield, WI | The Delafield Ho
tel

WORKSHOP: Developing a Risk Assessment & Management Process

Wednesday, March 31, 2010 from 8:00 AM – 5:00 AM (CT) Delafield, WI | The Delafield Hotel

 

OCEG BOOTCAMP Chicago: GRC Fundamentals, Strategy, & Technology

Wednesday, April 21, 2010 at 8:00 AM – Friday, April 23, 2010 at 5:00 AM (CT) Chicago, IL | The Ambassador East Hotel

Additionally, my social networking has continued to increase. This newsletter goes out to over 6,000 subscribers. My Corporate Integrity LinkedIN Group now has nearly 1900 members. And I have over 650 followers on Twitter. And my blog continues to get significant traction and reference.

That concludes my 2010 update – now back to serious GRC strategic planning and work

For the past two years Archer Technologies has been a disruptive force in the GRC market. They have been going strong in the IT/information security segment of GRC for several years – but the past two years has shown them to be a formidable competitor in what is referred to as the enterprise GRC (eGRC) market.

The following is an abstract from my latest research piece “Enhancing Business Performance through Risk Management“

While the market seems eager to grasp onto the phrase “risk intelligence,” it means nothing if corporations cannot take action on the intelligence it provides. Being intelligent is not the same as being wise – most organizations lack both risk intelligence and wisdom. There are organizations that acquire a lot of information, but without transforming this information into knowledge by understanding the context of their business risks, they fail to make better business decisions. Risk is often completely disconnected from business strategy, objective, and performance management.

Risk management requires the proper context across the entire culture of an organization. The only way an organization can manage risk appropriately is if acceptable and unacceptable risk tolerances and appetites are defined and managed. The culture of risk tolerance at all levels helps formulate these tolerances: This is where risk management relies on governance. The board and management must clearly define and communicate the organization’s culture of confronting risk. If the governance function does not do this, risk strategy is left up to individuals and the integrity of the organization is in jeopardy.

A mature risk-management program does not operate in isolation from the business. A mature risk-management program is integrated with corporate performance, strategy, and objective management. This requires that the organization relate performance to risk, allows for multiple inputs impacting the risk environment from both internal and external contexts, and has a variety of ways to look at risk information to analyze, model, and relate risk back to performance and strategy.

Effective and mature risk management delivers:

• Alignment of risk in the context of business strategy. Risk strategy is fully integrated with business strategy where business management realizes risk management is an integral part of business responsibilities.
• Risk intelligent business decision-making. Risk-management culture and policies are effectively applied across the organization, supported by management. The business has what they need to make risk-intelligent business decisions.
• Risk-based business planning. Risk is a key component in business planning. Risk assessments and reports are structured to complement the lifecycle of the business to help executives and the board make effective decisions.
• Establishment of risk culture and policy. Risk policy is clearly communicated across the business and is effective at establishing a culture of risk management. Risk policies are current, reviewed and audited on a regular basis.
• A risk appetite harmonized with business strategy. Risk appetite and tolerance levels are established and reviewed. They are mapped over to business performance and objectives.
• Integration of risk and performance monitoring and metrics. Defined KRIs are in place and appropriate mapped to business KPIs. Risk indicators have established limits/thresholds, and are defined at all levels of the business, its operations, and relationships.
• Communication of business relevant risk information. Risk reporting and indicators are relevant to the business and effectively communicated. Risk information adheres to information quality, integrity, relevance, and timeliness to the business.
• Ownership of risk within the business. Every risk, both at the enterprise as well as business process level, has clearly established risk owners. These owners represent roles that can take action on the risk.
• Holistic awareness of the range of risks the organization faces. The organization has defined risk taxonomy at the enterprise level which drills down into specific risk areas. A regular process is in place for risk identification to keep the taxonomy current. Various risk frameworks used across the enterprise are harmonized into an enterprise risk framework.
• Multi-perspective risk analysis. The organization uses a range of risk correlation, stress testing, and scenario analysis. Various qualitative and quantitative risk analysis techniques are in place and the organization has an understanding of its historical loss to feed into analysis.
• Effective risk treatment in context of business objectives and strategy. Risk treatment plans – whether acceptance, avoidance, mitigation, or transfer – are in place and monitored for progress. Audit functions conduct regular reviews. The solution reviews risk-treatment plans.
• Governance of risk from the board down into the business. The organization has a role and system in place to aggregate risk information across the business and effectively communicate, monitor, and manage risk. There is effective communication and accountability for risk oversight at the board of director’s level.
• Visibility of risk as it relates to performance and strategy across the business. An enterprise view of risk is in place and maps over to corporate performance and strategy. Risk is effectively communicated to stakeholders and the organizations track record shows successful taking and management of risk.
  Consistent ranking and measurement of risk. Risk is categorized and structured according to its impact on business strategy, performance, and optimization.

Successful organizations face the challenge to move from immature to mature approaches to risk management. Immature risk-management programs operate in silos and are disconnected from each other: no consistency or efficiency is gained. Many ERM programs are not much better than this, as they are nothing more than an enhanced SOX strategy, focusing on a slightly expanded view of financial and other internal controls. A mature risk-management program is a seamless part of business performance, strategy, and objective management. Risk must be managed within the context of business. This requires the organization to take a top-down view of risk led by the executives and board, and make it part of the fabric of business, not an unattached layer of oversight.