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.

Over the past few weeks we have looked at both theinformation model and the enterprise application core of Corporate Integrity’s GRC Reference Architecture. The GRC Reference Architecture provides the framework to approach technology, classify software offerings, and is part of my broader GRC EcoSystem (which includes over 1300 technology, professional service, and information providers). The GRC Reference Architecture represents the core to the revisions to the OCEG GRC IT Blueprint to be released by the end of this year. Your feedback is appreciated.

We now turn to the next component of the GRC Reference Architecture – the business role/function specific applications. These are the applications that are predominantly focused to meet the needs of a specific business function, process, or role in the enterprise. Applications in this area may very well have significant risk and compliance relevance as well as impact on the enterprise – but they are 80% or more used to a specific subset of GRC user roles. The enterprise application core that we previously discussed represents applications that span GRC business users/roles across the business.

The various business roles and functions that have specific uses of GRC technologies and applications are scattered across the enterprise. In one sense, every part of the business touches on GRC as it relates to different aspects of performance, risk, compliance, values, and control.

The primary, but not all inclusive, business function/role application categories include:

• Audit. While audit is a broader part of the enterprise application core of GRC, audit also maintains its own category of role specific applications dealing with assurance, audit management (e.g., calendaring, resource scheduling, work paper management), as well as audit analytics and automation.

• Brand & Reputation Management. This category offers targeted solutions for management the corporation’s brand and reputation – in both the physical world as well as online. This includes brand surveillance management.

• Business Continuity. From disaster recovery, business continuity, as well as crisis management – all are very relevant to GRC and are solutions that enterprises need to manage and maintain continuity of operations across the business.

• Business Operations (line of business). The line of business is the front line of GRC. From management of global trade compliance, procurement management, to customer relationship management . . . many aspects of business transactions, interactions, and relationships have relevance to GRC.

• Corporate Compliance & Ethics. Within corporate compliance and ethics there are solutions aimed at communicating code of conduct, delivering compliance training, as well as whistleblower reporting through hotline/helpline systems.

• Corporate Secretary. Board and entity management software is the primary vehicle for the corporate secretary role to carry out the function of managing board papers, communications, calendars, and corporate reporting.

• Corporate Social Responsibility/Sustainability. CSR is a burgeoning and growing field becoming increasingly relevant to organizations around the world. Solutions in this category aim to help monitor emissions and carbon tracking, as well as offering broader GRI (Global Reporting Index) reporting.

• Environmental, Health, & Safety. EH&S software helps the organization manage and maintain environmental controls as well as the health and safety of individual employees, partners, and clients. Solutions in this space have many offerings from areas like environmental monitoring and reporting to MSDS management.

• Finance & Accounting. The finance and accounting function focuses on using software to manage risk and compliance within business financial transactions, validates that the organization is managing finance and budgets within boundaries, and monitors finance and treasury risk management. This entire area is often referred to as Finance-GRC.

• Fraud. The area of fraud management utilizes software for fraud investigations, fraud prevention/management, as well as specific areas such as anti-money laundering.

• Human Resources. HR issues from hiring practices, discrimination, harassment, wage & hour, compensation, employee privacy, and other areas often carry some of the most significant risk and compliance risks the organization face. While broad HRMS systems have much relevance to GRC, there are specific areas of software that HR leverages to help communicate and prevent issues of risk and compliance such as employee evaluations and surveys, as well as learning/training management solutions.

• Information Security, Risk, & Compliance. What is often referred to as IT-GRC represents the most expansive domain of software solutions aimed at managing technology and information risk and compliance. This includes areas of threat and vulnerability management, configuration management, identity and access management, encryption, and many other components.

• Insurance. The role focused on managing insurance and claims management has software specifically aimed to support its function in GRC.

• Investigations. Part of the broader enterprise GRC application core as well, investigations management software enables the organization to consistently and efficiently intake issues, manage investigations, and record and manage loss across the organization.

• Legal. The legal department has a variety of technology solutions aimed at supporting the legal role in areas such as matter management, contract management, discovery management, and the management and protection of intellectual property. The terms Legal-GRC and legal process management are starting to be used to identify solutions that bring these components together.

• Physical Security. Physical security is dependant on many areas of technology for surveillance and physical access systems to protect the organization, and in some areas to comply with laws and regulations.

• Privacy. A variety of solutions have come to the market specifically aimed at managing privacy programs. These include software focused on information protection, privacy policy communication and training, to incident response and managing disclosure requirements.

• Quality Management. Quality management systems provide a backbone of managing quality within the line of business – while monitoring and resolving quality and control issues.

• Risk Management. Risk is a fundamental core to GRC but also has a variety of business roles across the organization. From enterprise risk management software, down into the bowels of many components of operational, geo-political, and financial and treasury risk management software – there are solutions aimed at meet
  ing a variety of specific risk needs.

• Third-Party/Supply-Chain Management. Risk and compliance issues do not start at the traditional corporate boundaries but carry on to a complex web of business partner and supply chain relationships. Solutions in 3rd party management aim to communicate code of conduct and policies while managing and monitoring risks, compliance, and controls across extended business relationships.

These roles represent a significant but not exhaustive look at the categories of risk and compliance software solutions targeted at specific areas of the business. These applications need to be able to report and feed information into broader GRC reporting systems and dashboards to maintain a 360 degree view of GRC throughout the business. All are very relevant and part of a broad GRC strategy.

Further, the discussion and breadth of GRC business/function roles and supporting technologies underline the fact that GRC is a federated effort. There is not one group of the organization that does GRC. While there may be a role leading the collaboration, it really extends throughout the business.

Over the next few weeks we will wrap up the initial discussions on the GRC Reference Architecture. The next posting will provide commentary on the geographic and industry specific views of GRC technology, and the final one will look at the technology components/capabilities that GRC solutions are comprised of.

Detailed training on the GRC Reference Architecture can be found in Corporate Integrity & OCEG’s GRC Strategy & Technology Bootcamps.

Friend,

Last week we began our presentation of the GRC Reference Architecture, which is part of my broader GRC EcoSystem (which includes over 1300 technology, professional service, and information providers). The GRC Reference Architecture is the core to the revisions to the OCEG GRC IT Blueprint – for those of you interested in the OCEG Technology Council we will be reviewing this architecture, the changes to the GRC IT Blueprint, and upcoming projects via a 2 hour web conference on November 13th (contact me as I chair the OCEG Technology Council).

The GRC Reference Architecture is comprised of: information model/framework, enterprise core GRC application(s), role/business function specific applications, as well as industry and geographic/jurisdiction specific applications.

In the previous posting we looked at the heart of the enterprise GRC information model and framework. This provided a high-level conceptual on the different data areas that interrelate with each other to form the enterprise core of GRC. The core of the GRC Information Model and Framework relates core GRC libraries of information across the organization, including the objective, risk, control, event, responsibility, policy, requirement, and enterprise (business model) libraries.

This week I provide the outline of the enterprise GRC core applications that interact, share, and leverage the information model to deliver sustainable, consistent, efficient, transparent, and accountable GRC processes. To be an application at the enterprise core of GRC requires that the application be used across the business as a platform that touches and interacts with a variety of business roles and information. This provides the foundational application(s) that make deliver on the GRC philosophy of a common architecture and collaboration across business roles and interests.

There are dozens of application categories that fall outside of the enterprise GRC application core – those are the ones that are focused on specific business roles and functions (e.g., quality, EH&S, matter management). We will look at a framework for those next week.

The enterprise GRC application core consists of the following applications:

• Strategy, Performance, & Objective Management. This is the missing application link of GRC. So many GRC applications focus on the downside – avoiding the bad – that it fails to relate to the upside of why organizations take risk and maintain control: business performance and optimization. Governance is about directing the organization on a specific course, risk is taken to achieve objectives, and compliance is there to stay within boundaries so the organization does not get off course. A successful GRC application is going to integrate business strategy, performance, and objective management to provide context to risks, controls, policies, and assurance. GRC applications need to be a fundamental part of corporate performance management systems.

• Risk Management. Risk management applications come in all shapes and sizes. Most are very niche focusing on specific business risk areas such as market, commodity, security, and other risk areas. However, at the enterprise GRC core is the application that brings all the silos of risk scattered across the business together to form the foundation of an enterprise risk management (ERM) system). This is the system that defines the organizations risk library (risk taxonomy) and is the central system for doing risk assessments/surveys, identification, analysis, treatment, ownership, modeling, and monitoring of risks across the enterprise. The risk management system interacts with corporate performance systems to map key risk indicators to key performance indicators. It provides the consistent engine to communicate and assess risk across the business.

• Audit & Assurance Management. The role of audit is central to GRC. While audit and assurance management can easily fit into a specific business function/role application used by internal audit, it is necessary that it be part of the enterprise GRC core. Audit interacts with all parts of the business (at least it should) to provide assurance that the organization is staying within the boundaries of policies and control that management has defined. The audit management platform becomes core to GRC as it provides audits to all aspects of the business and its relationships and gives other business roles a place to interact and comment on their thoughts to audit findings. The audit management platform delivers resource scheduling, calendaring, work paper management within a consistent application and framework. Audit management systems should leverage and use the same information libraries of risks, controls, policies, objectives, and even events that other GRC roles are using as part of the audit process.

• Event & Case Management. It is unfortunate – organizations are in a complete disarray of how they manage investigations, issues, incidents, events, cases (or whatever other synonym that works best for your business area). As a result the organization lacks any good source of understanding losses and issues across the organization. An organization cannot do good risk management if it does not know what the history of losses and materialized risks have been. Events also trigger where policies are ineffective, out of date, or not understood. They also identify where controls are not working – or where further controls are warranted. Organizations need a central library of managing events and cases across the enterprise. This application area focuses on consistent documentation and management of events – from reporting, to managing and documenting the investigation, to recording the loss and business impact. NOTE: I am working on a published research piece to be available in December on Event & Case Management systems which will provide an overview of several applications in this space.

• Policy & Procedure Management. Similar to Event & Case Management, how organizations manage policies and procedures is out of date and ineffective. Organizations are quick to drop policies into a SharePoint site where they have no management in place to govern them. In my policy & procedure audits I have found organizations with dozens of policy publication sites and manuals. Many with out of date policies that lack policy owners and have not been reviewed for meeting the organizations needs in years. Further they are often written with different language and formats – without a thought to a corporate standard for style and language. When you ask about policy exceptions – the organization has no idea how many have been granted. Policy management and communication is a core area of defining corporate culture and values, it is also where the company can quickly get in legal and regulatory turmoil if done in an ad hoc manner. Organizations need policy management systems to manage the lifecycle of policies from ownership, development, approval, communication, exception management, periodic maintenance, and archiving. Part of this involves the ability for any role in the organization to login and see which policies relate to their job, what policy
  training and attestations are required, and what testing/quizzing needs to be done. In the day of YouTube I am seeing demand to deliver policies and associated training within the same environment – particularly as more and more laws are being written that require training and understanding of requirements and compliance. Policies relate back to risks as they establish the risk culture and tolerance of the organization, they relate to helping the organization meet objectives by staying within boundaries of control, they relate back to events which identify where policies have been violated . . . you get the picture. NOTE: I will be approaching a published research piece on the components and vendors delivering Next Generation Policy & Procedure Management in February.

• Compliance Management. Compliance is a confusing word as it has different meanings and connotations (as with Risk and Governance). Elements of compliance management can be found in all of the other application areas – policy and event management are both central to a good compliance program. This particular domain of compliance management is the assessment engine to deliver surveys and self-assessments across the business and its relationships to understand and report on the state of compliance and control within the organization. It links to the policy and control libraries to build compliance assessments and delivers these to the business in a consistent interface across the organization. It is separate from audit management as audits are the independent validator of compliance while the compliance management application is management’s tool to make sure it is staying within mandated and voluntary boundaries of control.

• Control Monitoring, Automation, & Enforcement. Related to compliance management is the world of compliance and control automation. The goal of this suite of GRC applications is automate the validation and enforcement of controls within business processes, systems, and information. This encompasses an array of solutions that deliver control monitoring, automation and enforcement across business transactions, configurations of business systems and applications, segregation of duties, and validation of master data records. While many applications in this space have been focused in niche areas (e.g., SOX SoD), Corporate Integrity is seeing growth and expansion of this technology to be enterprise applications across risk and compliance areas.

• GRC Dashboards, Reporting, Analytics, & Modeling. It is this area that provides the reporting glue across GRC domains. The GRC enterprise application core requires a central hub that integrates all of the information into a common interface to deliver metrics, dashboarding, reporting, and measurement of GRC activities across the business. It is here the organization looks to deliver the command and control center for GRC activities.

The enterprise GRC application core provides the foundation of GRC across the business. All of the applications referenced are ones that can be leveraged from one side of the business to the other – providing a consistent approach to GRC across silos of risk and compliance. However, there are a variety of business functions and roles that have their specific needs that demand applications aimed for their business function. Next week we will take a look at the application categories aimed at specific business roles and functions that plug into the broader GRC Reference Architecture.

Detailed training on the GRC Reference Architecture can be found in Corporate Integrity & OCEG’s GRC Strategy & Technology Bootcamps.

GRC – Governance, Risk, & Compliance. Whether you use this specific acronym or not the fact is your organization does 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: GRC has been a part of business since the dawn of business.

GRC is akin to CRM (Customer/Client Relationship Management) in 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 ended up with inconsistent and redundant data with no view into 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 interactions across business processes and roles. GRC systems and processes aim to achieve the same thing – to provide an integrated picture of governance, risk, and compliance information and processes across the business. To accomplish an integrated view of GRC requires the establishment of a GRC business process and technology architecture.

In the next several newsletters I am focusing on the communication of Corporate Integrity’s GRC Reference Architecture. This GRC Reference Architecture is party of my broader GRC EcoSystem of technology, consultants, and information providers (over 1300 firms cataloged to date). It is also the foundation of the revisions going into OCEG’s GRC IT Blueprint.

The GRC Reference Architecture is comprised of: a data architecture/framework, enterprise core GRC application(s), role/business function specific applications, as well as industry and geographic/jurisdiction specific applications.

This week we look at the information foundation (from a high-level) in the Enterprise GRC Data Architecture & Framework. A firm foundation is necessary to build extensible and agile GRC system and processes.

Intricate relationships between different information the heart of a successful GRC technology strategy. When I was in grade school I loved it when the teacher had us draw points around a circle and draw lines connected to every other point resulting in a beautiful geometric pattern that captivated the eye. The same visual represents the many to many relationships of GRC information. If you think about it – policies, risks, controls, events, requirements, enterprise assets/processes, responsibilities, and objectives all map to each other. Organizations need to know what policies set management thresholds for specific risks; what events happened that violated specific policies, materialized risk, and caused an infraction of a regulatory requirement; what controls are established in specific policies and defined to control what risks; which business objectives are risks related to and how do we monitor controls to stay within acceptable tolerance levels of risk while aiming for that objective.

The core of a GRC Data Architecture and Framework integrates the following libraries of information within the organization:

• Objective library. This is often the missing piece of GRC. Most GRC strategies are focused on meeting requirements and putting out fires of risk. However, governance starts with understanding corporate performance, business strategy, and objective management. A good GRC system will define business objectives and cross-reference those to risks, requirements, and other areas of GRC.

• Risk library. The problem with risk management is that it often happens in silos and there is no aggregate view of risk. Organizations need a consistent data framework to define, manage, and monitor risks. This requires that risks be mapped to objectives but also to other elements such as controls implemented to treat risks, events that show where risk has materialized, responsibilities to define risk owners, as well as policies used to establish and set thresholds of risk.

• Control library. Controls establish the fundamental building blocks of a GRC program. They aim to make sure the organization is staying within boundaries of risk and compliance while allowing the organization to pursue its objectives. Controls are in place to protect the organization. A good GRC system will allow for the cross referencing of controls to business objectives, risks, events (control failures/weaknesses), policies, regulatory requirements, as well as the business environment of processes and assets.

• Event library. Whether called cases, events, incidents, issues, investigations . . . the organization aiming for an integrated and efficient GRC system will need a common repository of events and losses that have impacted the organization. This starts with the recording of an event, the documentation on investigation and response, to allocating loss information that feeds into risk models. Events document policies that were violated, actions took, control issues/weaknesses, responsible parties as well as what part of the organization was impacted.

• Responsibility library. Every business objective, risk, policy, requirement, business asset has something in common – an owner. Businesses get into a world of hurt when they do not know who is responsible for what policy, risk, regulatory requirement, etc. Defining ownership of the components of GRC is essential to a successful risk and compliance strategy.

• Policy and procedure library. Policies set the boundaries of the organization – they establish the expected/required behavior of individuals, systems, processes, and relationships within business. At the highest level they articulate values and code of conduct, at the detailed level they tell you exactly where boundaries lie. Policies map to risks to establish risk culture, tolerance, and appetite; they map to events where an organization can see where policies have been violated; they map to controls as specific statements within policies often are the control statements themselves; they map to requirements to meet specific boundaries set forth by regulators; and they also map to the enterprise as policies govern everything from the entire business (e.g., code of conduct) to specific business operations/processes.

• Requirement library. The focus of GRC is to stay within boundaries while achieving business objectives. A central store of requirements from regulators, laws, code of conduct, ethics, values, social responsibility, contracts . . . allows the organization to document what it has to be compliant to. This enables the mapping of requirements to policies, risks, controls, business objectives, enterprise assets/processes, as well as events that identify where a requirement has been missed.

• Enterprise library. No matter what area of GRC information you are looking at it applies to something in the organization. It can apply to the whole organization such as a code of conduct, or a specific business unit, process, entity, business relationship, employee/role, or event information category itself. Organizations that successfully approach GRC have established enterprise modeling to relate objectives, risks, controls, events, policies, responsibilities, and requirements to the business.

Illustration: last week I was discussing the role of GRC applications and information and how they integrate with a global professional services firm looking to implement a GRC strategy and solution to govern their internal operations. They asked – “We have been using Sharepoi
nt for policy management, does this need to be part of the GRC system?” My reaction was that this the approach many organizations take but challenged them to consider the intricacies of this approach which would handicap their GRC strategy. These included challenging them if they have a central and authoritative repository of all policies? Do they have a way to manage the lifecycle of policies from authorship, approval, communication, regular/periodic maintenance, training, attestation, and archiving of policies? Do they have a way to track exceptions to policies? More specifically to the relationship of policy information – can they map policies back to regulatory requirements, risks, controls, business objectives, as well as the events/investigations in which policies were violated? It was at this point they saw the picture of why an integrated GRC system adds value across the business silos of risk and compliance that have gone in different directions in the past.

This is just a high-level view of the core data components of a GRC architecture. Next week I will publish the core enterprise GRC applications that leverage this data. Detailed training on the GRC Reference Architecture can be found in Corporate Integrity & OCEG’s GRC Strategy & Technology Bootcamps.

From the SCCE:

In the recent Corporate Integrity Agreement between Pfizer and the Office of the Inspector General of the Department of Health and Human Services, Pfizer agreed that its Chief Compliance Officer will report directly to the CEO; will neither be nor be subordinate to the General Counsel or CFO; and will make periodic reports to the Audit Committee of the Board. Does it negatively impact a compliance program when the GC is also the head of ethics and compliance? To whom should the chief compliance and ethics officer report? And how can a company create the right level of independence for the compliance function?

In order to gather valuable benchmarking data for our members, the SCCE has compiled 9 short questions regarding compliance officer positioning. Please take a minute to answer the survey, then check back to view the valuable benchmarking data. Thanks very much for your participation and your important contribution to compliance and ethics benchmarking research.

Thank you very much for providing your valuable input.
http://scce.informz.net/z/cjUucD9taT00OTEzMTImcD0xJnU9MTAwNzkwOTEwOCZsaT0xODExMTE4/index.html

Besides taking the survey – please post your comment on this LinkedIN group.