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.

Success in today’s dynamic business environment requires the organization to integrate, build, and support business process with an enterprise view of risk and compliance.Without a new approach to risk and compliance, the scattered and non-integrated risk and compliance approaches of the past fail and introduce greater risk and regulatory threats to the business.A sustainable enterprise view of risk and compliance is one in which accountability is effectively managed and the business has a complete system of record – providing visibility to assess across a multiplicity of risk and compliance issues. This is supported today by technology that allows for the direct integration of controls within business systems to prevent and/or detect unwanted behavior. Business now requires that governance, risk, and compliance (GRC) controls be integrated into business processes, systems, and applications.

With new risk and compliance issues constantly coming to bear, organizations need to tackle the problem at its roots.Instead of treating each risk and compliance issue as an individual problem (as they have in the past), organizations need to define a common process and technology architecture to manage risk and compliance across the range of issues faced.

The old paradigm of managing risk and compliance is a recipe for disaster. Organizations have been reactive as they used manual or point solutions for risk and compliance while being extremely fragmented in managing risk and compliance as individual efforts that do not relate to a broader risk and compliance. A reactive approach to risk and compliance leads to siloed initiatives that never see the big picture.The result is complexity, redundancy, and failure.The organization is not thinking how controls and processes can be architected to meet a range of risk and compliance needs – NOR do they gain an understanding on how risk management and compliance control impact corporate performance.An ad hoc approach to GRC results in poor visibility across the organization and its control environment, as there is no framework or architecture for managing risk and compliance as an integrated part of business.

What may seem like an insignificant risk in one part of the organization may very well have a different appearance when other risks are factored into its relationship and impact.Organizations face out-of-sync controls and corporate policies that are inadequate to manage risk and compliance. Organizations fail and are encumbered by unnecessary complexity because they manage requirements, risks, and controls within specific issues and do not look to see how a common integrated framework and architecture can bring efficiency to GRC processes. Further, executives are becoming aware of these redundant risk and compliance projects from different parts of the organizations wasting company time and resources with manual and laborious assessments that fail to leverage technology and information.

Modern business requires a new paradigm in tackling risk and compliance issues across the enterprise.No longer can organizations afford to focus on single risk and compliance issues as unrelated projects and assessment, nor can they allow software band-aids to masquerade as GRC that is not integrated into business systems.A targeted strategy addressing GRC requirements through common processes and integration into enterprise applications gets to the root of the problem. The risk and compliance complexity in today’s business requires a common strategy and architecture to effectively manage GRC. GRC is a three-legged stool:governance, risk, and compliance oversight are each individual but interrelated necessary components for effectively managing and directing an organization. In summary – good governance is built upon diligent risk and compliance management processes.

GRC solutions that operate autonomously from business processes introduce further risk in today’s complex and distributed business environment.Organizations require an enterprise view of GRC that not only brings together silos of risk and compliance, but integrates them into the enterprise process and application fabric of the business.

In today’s business environment, ignoring an integrated view of GRC results in business processes, partners, employees, and systems that behave like leaves blowing in the wind. Organizations face a complex array of risk and compliance demands impacting business. The more extended and distributed the business – the more challenging risk and compliance is to manage. An integrated GRC architecture aligns them to be efficient and manageable. Inefficiencies, redundancy, errors, and potential risks can be identified, averted, or contained.This reduces risk exposure of the organization and enhances business agility and performance.

Organizations are embracing technology to get away from document centric approaches to GRC that are based on paper, electronic documents, and spreadsheets.Organizations require a GRC architecture that can expand and contract to ever changing business initiatives over time.However, the first generation of GRC solutions have often been limited as they end up being a band-aid to replace spreadsheets and lack true integration into the enterprise application fabric and business processes. A primary consideration is the flexibility of the GRC architecture to enable the identification and resolution of business problems.

Continuously monitoring risk and compliance has become imperative but it’s only cost effective if the organization has a strategic approach to managing controls across risk and compliance initiatives. The business is in an awkward position of reacting to mandates where it should be proactively managing controls and risk.The web of stakeholders with varying risk and compliance requirements appears to introduce a complex tug-of-war with opposing priorities.GRC requirements, risks, and controls have an impact on corporate strategy and performance and need to be monitored as part of an overall corporate performance strategy.

There is significant redundancy in requirements, technologies, and processes across risk and compliance issues impacting the business that can be addressed by a common architecture and process approach to GRC.

Efficiency in risk and compliance processes is achieved through the definition of common processes and integration into the enterprise application environment that different stakeholders can utilize for their individual requirements as well as collaborate and share.A successful GRC strategy is one that has a symbiotic influence on the variety of business stakeholder roles and their common requirements.

Sustainable risk and compliance programs are built upon a common process and technology architecture designed to meet a range of requirements impacting the business.Organizations need to be intelligent about what processes and technologies they deploy – the goal is to define once and comply with many regulations, manage a range of risks, and maximize value from the convergence of technology, people and process.A sustainable approach to GRC results in an organization that is looking to the future and mitigating risk in the course of business as opposed to putting out fires by reacting to risk and control issues as they arise.

Risk and compliance management is complex with numerous individual intricacies and issues ready to frustrate the organization.Organizations that attempt to build a GRC strategy with home-grown solutions, spreadsheets — or islands of technology that do not integrate into the enterprise and processes — are left in the dark and boxed into a view of the world that they will find limiting down the road.

The
case has been laid that the current business environment requires a new paradigm of GRC technology – a platform that spans across the organization and its individual risk and compliance issues, integrates into enterprise applications, becomes an integral part of business processes, brings together a GRC strategy ready to tackle risk and compliance issues at their roots, and is critically linked to corporate performance and strategy.

While comprehensive GRC is much broader than technology – GRC cannot be accomplished without technology.Technology is the foundation of GRC processes and provides the backbone of GRC communication and collaboration.

Getting started on a sustainable GRC strategy requires that the organization get a current assessment of where they are today, what is in place and already deployed, identify redundancies in technology, and find areas that might have been addressed but where the solutions are not scalable or manageable at an enterprise level.The gap analysis is aimed to not only identity the current state but to also help the organization prioritize their roadmap going forward.

One thing is a certain – risk and compliance burdens are not going away.Government regulators continue to influence control upon organization practices through tighter regulation.Business partners are requiring stronger controls within their relationships.The globalization of business introduces significant risk with more points of vulnerability and exposure to the organization.The time is now for organizations to define and implement a sustainable GRC strategy that drives accountability, security, sustainability, consistency, efficiency, and transparency of GRC across the organization.Selecting the right technology vendor that provides the integration and enterprise control of risk and compliance is a critical step that organizations should not take lightly.

This article is an excerpt from my latest written research piece on the topic. Additionally, a corresponding webinar has been posted at OCEG. For those that want the best training on the subject of GRC Strategy and Technology Enablement – see my workshops below. Please comment on this article on the GRC Pundit Blog.

Most GRC software as well as GRC implementations are more like RC (without the G). Or just R or just C. Or perhaps Rc or rC. . .

My position for this discussion – we cannot adequately state we are doing the G in GRC unless we are also taking into account business objectives, strategy, and performance. That is what corporate governance is about. Staying within boundaries for compliance, and managing risk plays into this. But the GRC solutions and initiatives do not really do the G.

Thoughts?

For one thing – that would be too much of an acronym CGRCO. The subject actually came up in a corporate governance discussion group I belong to. Michael Corcoran posted the question “Anybody know of a Chief Governance, Risk And Compliance (GRC) Officer?” and provided a short article in which he was advocating this role.

While GRC is ultimately about collaboration and communication between the business roles and processes responsible for varying risk and compliance functions, there is no doubt that technology has an important role in facilitating this enterprise cooperation.

As a result . . . I am combing my work on the GRC EcoSystem with the second version of OCEG’s GRC Technology Blueprint. Both are going through a revision process to provide a valuable framework to understand the scope and application of technology to meet GRC purposes. OCEG decided to move IT Blueprint into a version 2 to make it more practical and applicable to organizations trying to implement technology to provide an architecture for GRC.

NOTE: Your Feedback is Requested!

Based on my experience as an industry analyst, I have put together a new high-level framework addressing GRC and its components. Attached to this newsletter you will find a PDF labeled theGRC Technology EcoSystem which is the backbone for the restructuring of the IT Blueprint at this point. Looking at the file you will find at a high level the blueprint is broken into the following areas:

• Enterprise GRC Architecture/Applications. Represent the solution areas that span risk and compliance roles and processes that organizations can leverage and use as the backbone for a GRC strategy. The technology categories in this area are listed below in brief definition. These solutions are not locked to a single role but something multiple roles/business functions/processes can leverage. I feel this area is fairly solid, but appreciate your feedback.
• Role specific Applications. This provides a list of GRC related roles within the organization and specific application categories that serve these specific roles. There is still much to be built out in this area and would appreciate your feedback on these specific roles and the application categories that serve them. There are some technologies, such as audit management, that are essential for a strong GRC strategy – but they serve primarily a single role, audit.
• Industry Specific Applications. It is in this category that applications/technologies aimed at a specific industry vertical are mapped. An example is the several technology providers aimed specifically at helping life sciences companies comply with GxP. Or there are other solutions aimed at Medicare/Medicaid RAC audits. Or NERC in the utility space. This area has a lot that can be built out. I would love your feedback on getting to a standard for representing industries that is not too narrow nor broad. I would also appreciate your feedback and experience on applications focusing on specific industry issues.
• Geography/Legal Jurisdiction Applications. This is the most rough, and I am not sure how it will be built out. This is the thought that there are specific legal jurisdictions that might require a specific solution for GRC purposes. Thoughts?
• Technology Architecture Components. This is a listing of feature/functionality that any given product in any of these areas might bring together to deliver a solution. It also may represent the IT platform/architecture tools that organizations can build their own GRC platforms out of if they were not going to invest in a commercial product. As for commercial products, a buyer should be able to evaluate them and identify if such technology components as content management, workflow, and other components are part of the platform being implemented/considered. Of course, varying GRC related solutions (and there are over 500 vendors and 1000+ products in this space) can be utlizied in a variety of technology delivery capabilities such as software as a service, hosted application, or traditional software model.

Now to give you some brief definition to the Enterprise GRC Architecture/Applications, and again I request your feedback and input, they are as follows:

• Accountability Management. This provides an enterprise platform to manage the accountability/ownership of risks, controls, policies, incidents/loss, and GRC related processes. Every silo of risk and/or compliance should have someone accountable as well as specific policies, investigations, loss, risks, assessments, etc.
• Assessment & Survey Management. This is the enterprise platform for delivering a common assessment and survey tool/process. Of course, at a basic level this could be spreadsheets – and often are. At the right implementation level it is a consistent tool to deliver, track, and record survey/assessments for risk, control, and compliance purposes.
• Asset/Process/Entity Register/Taxonomy. If you think about it – every risk, control, policy, loss, requirement applies to something in the organization. It is important that organizations have an ability to model their organization structure, roles/employees, business relationships, processes, physical environment, logical environment, and information. From there – risks, controls, policies, and so forth can be applied to the assets/processes they apply/belong to.
• Continuous Control Monitoring/Automation/Enforcement. This is the category to provide an enterprise platform for the continuous monitoring and automation of controls – both preventive and detective. This includes continous/automated monitoring of (1) IT infrastructure, (2) application permissions, (3) records/data, and (4) business transactions.
• Control Registry/Taxonomy. It is here that the organization provides a catalog of its controls, as well as versioning of controls to provide a history/audit trail. It is in this category that the broad spectrum of controls is defined and managed.
• GRC Dashboard & Reporting. This is the core capability necessary to analyze and report on the breadth of GRC related data across the enterprise.
• Hotline/Helpline. It is here the organization deploys a centralized web-reporting and/or call center where employees, clients, partners, stakeholders can report wrong doing and/or suspicious activity as well as seek help on certain compliance, risk, ethics, and code of conduct topics.
• Identity & Access Management. My research this past year has caused me to elevate this to an enterprise issue, and not just an IT risk and compliance category. Organizations need an enterprise approach to cataloging identities, access, entitlements to both the physical and logical business environments. If you think about it, a lot of risk and compliance issues comes down to who has access to what, what can they do with it, etc.
• Investigations/Incident/Loss Management. This represents an enterprise platform/ability to consistently document and manage the process/workflow of investigations. It also provides a common platform for tracking and monitoring losses the organizations has experienced.
• Policy & Procedure Management. It is here an organization builds/delivers a solution to provide a consistent interface and user experience to manage the development, approval, communication, maintenance, and archiving of corporate policies and procedure documents. This also includes training management related to those policies and proc
  edures.
• Requirements Register/Taxonomy. It is in this category that organizations document and breakout the specific chapter and verse of regulatory, legal, and standard guidance. This is the registry that defines the mandatory and voluntary boundaries by which the company is governed – it defines the lines that should not be crossed and what is required of individuals, processes, business relationships, etc.
• Risk & Regulatory Intelligence. Organizations need the ability to monitor the internal context of risk and compliance as well as the external context that business operates within. This represents the category of technologies that can take information from data feeds and turn them into tasks/workflows routed to the right individual to make a decision on a changing business, risk, and/or regulatory environment and how it impacts the organization.
• Risk Analytics & Modeling. Some might see this as part of GRC dashboards and reporting, but the area is complex and can stand on its own. This represents the organizations ability to display and model risk. At a simple level it is heatmaps, at a complex level it may involve monte carlo simulations, bayesian modeling, or value at risk.
• Risk Register/Taxonomy. This represents the enterprise catalog of risks. Like the other register/taxonomy items above the purpose is to not only define, but also to cross-reference risks to loss, policies, controls, assessments, etc.

Thank you for your attention to this. Within the next week (end of day on Sept 25th) I need your reaction/thoughts on this.

During my latest OCEG GRC Strategy & Red Book 2 Bootcamp, one attendee stated they had seen the job title of Chief Punishment Officer in China. Any takers?

On a related note – one attendee had asked if anyone had a disciplinary matrix – wrongs with associated punishments – for their organization.

My apologies. Along with my commentary on Forrester’s GRC Ripple (OOOPS . .. I Mean Wave) I had promised to provide my thoughts on Gartner’s EGRC Magic Quadrant once it was publicly available. Needless to say – August was a busy month, between end of summer trips, preparing for the fall, and kicking off the highly successful OCEG Red Book, GRC Strategy, & IT Bootcamps nearly a month has gone by without my comment. Better late than never . . .