Mid-sized and larger enterprises are constantly dealing with burdens like government regulations, legal battles, and brand damage. These burdens generate significant work associated with proving their positions to counterparties with various forms of evidence. Such evidence is often used in support of examples that include but are not limited to litigation, meeting mandatory government filings, and dealing with scheduled or even surprise audits by other companies and government agencies. As a means of dealing with such burdens and their related overhead such as the work associated for preparing and managing said evidence, the industry has migrated towards a common framework called Governance, Risk Management, and Compliance (GRC).
This article is not meant to be a full dissertation on all areas of Governance, Risk Management, and Compliance (GRC) but is, instead, intended to provide the reader with a quick and yet comprehensive overview of the key foundational elements for GRC.
This article will also act as a baseline for other articles that will elaborate further on topics mentioned, herein.
Common GRC Capabilities and Business Functions
- Driver Management: Seeks out, records, tracks and communicates those things that will require being in scope for GRC. Examples include but are not limited to:
- Regulations [e.g. Federal, State/Regional, County, City/Township, etc.]
- Franchise and License Control Bodies
- Industry Standards
- Contractual Obligations (e.g. Vendor Product Utilization Compliance)
- Policy Management: Establishes, tracks, maintains, and communicates internal policies that must be adhered to, in order to facilitate compliance with Drivers.
- Controls Management: Works with Control Groups in various GRC Control Areas to identify, establish key GRC Control Processes and Procedures. [Note: Is not responsible for the design and maintenance of such processes. The Control Groups are.]
- Control Organizations Establishment (for each Control Area)
- Control Roles and Responsibilities Establishment (for each Control Area)
- Control Processes (and Procedures) Establishment (for each Control Area)
- Control Tools Establishment (for each Control Area)
- Control Data Establishment (for each Control Area)
- Records Management (RM): A critical GRC capability that ensures records which are important to GRC are properly identified, tracked, maintained, shared, and disposed of. [Note: RM, by itself, is a significant portion of GRC and often requires dedicated staff direct involvement in the GRC Steering Committee, as records span across many different GRC Control Areas.]
- Audit and Compliance: Used to ensure adherence to and compliance with Drivers, Policies, Control Processes, etc.
- Internal Audit Management: Audits intentionally scheduled by internal staff to help test and maintain adherence to and compliance with Drivers, Policies, Control Processes, etc.
- External Audit Management: Audits initiated by external parties that wish you to prove your adherence to and compliance with Drivers, Policies, Control Processes, etc.
- Enterprise Risk Management (ERM): Used to assess and mitigate Risks for Driver Compliance. The purpose of ERM is to collect risks, measure and report on their probability of GRC Incident occurrence, and work with GRC stakeholders to mitigate such risks. ERM covers areas such as but not limited to: Regulatory Risk, Brand Risk, Operational Risk, Financial Risk, etc.
- Establishment and Management of Internal Operational Control Groups (a.k.a. Control Groups): These are the groups or organizations within an enterprise that operate within each of the different GRC areas.
- The GRC Steering Committee or Governing Body: This is the group of people who are responsible for Enterprise GRC, that establish and manage GRC as a function, and that make the decisions for who, what, when, where, and why things need to be a part of GRC. Done correctly, they also control the required GRC budgets.
- Incident Management: Addresses how to handle things like regulation and policy violations, including escalation, short term response, and long term remediation.
- Continuous Reporting: All GRC programs will require continuous informatics and data science capabilities to support reporting on any and all relevant GRC capabilities and business functions (listed in this section). Examples include but are not limited to:
- Regulatory Filings
- Franchise and License Filing
- Vendor Compliance Reports
- Risk Reports
- Audit and Compliance Reports
- GRC Incident Reports
- The Master GRC Dashboard(s) required for the GRC Steering Committee, Executive Leadership, and the Board of Executives/Advisors
- Communications: Ensures regular and appropriate communications to all internal and external GRC stakeholders and to the general work population, who should always be aware of GRC and its key initiatives.
- GRC Funding: Because GRC will be an ongoing initiative, it will require regular/consistent funding that should be controlled by the GRC Steering Committee.
A GRC Counterparty is a person or organization that is entitled to ask for proof or evidence of one or more of the controls your enterprise should be actively managing and maintaining. For example:
- a government agency that controls laws or industry operating regulations,
- a lawyer or law firm driving or involved in litigation against your enterprise (via subpoena),
- a vendor whose products you agree to use under specific contractual terms,
- a partner who you’ve opened your financial books to, under contractual agreement,
Internal Auditors commonly act as External Counterparties to regularly test adherence to and compliance with GRC Drivers.
Common GRC Control Areas
The GRC Control Areas are those areas or domains within an enterprise that are within the scope of GRC management. Examples of such areas include but are not limited to:
- Critical Manufacturing and Delivery Processes
- Facilities Management
- Physical Plant or Facilities Security (e.g. Gates, Doors, Turn Styles, Security Badge Readers, etc.)
- Enterprise Surveillance
- Library Management (LM) [Usually coupled closely with Records Management.]
- Regulatory Finance
- Information Technology (IT)
- Asset Management (both, Software and Hardware Asset Management)
- Data Center Security
- Systems Security (e.g. Computers and Applications)
- Cyber Security
- Information Management (Specifically for sensitive, confidential, and secret data. For example: PCI, PII, and PHI data.)
- Sourcing (The general term used for the acquisition of resources.)
- Human Resources Compliance
- Vendor Management
- Partner Management
While the above list of GRC Control Areas represents the majority of what larger enterprises have to worry about, keep in mind that you and your enterprise may need to customize the list by dropping some areas (because they may not be necessary for you) or adding some custom areas that may be required for your own enterprise or industry of operations.
GRC Control Groups
GRC Control Groups are those organizations that will establish, maintain, and be responsible for GRC Controls (e.g. Control Processes, Control Procedures Control Metrics and Measures). For example, your Information Technology (IT) organization may be very large but only very specific organizations within IT may be responsible for specific control areas, such as Identify and Access Management or Data Center Security Management.
Since GRC can impose a significant amount of overhead, it is important to minimize that overhead by ensuring your enterprise identifies and isolates specific GRC Control Groups for specific GRC Controls, in a manner that does not hinder their performance or the performance of other organizations that are not directly involved in GRC.
GRC Control Metrics and Measures
Every GRC Control will be required to have very clear GRC Metrics and Measures that will allow any auditor (internal or external) from any GRC Counterparty to prove compliance.
GRC Metrics and Measures will be used to drive, both, continuous and on-demand reporting for relevant GRC functions.
The GRC System
GRC Committees or Governing Bodies often attempt to establish one or more software systems to facilitate higher level GRC functions. These systems are often referred to as GRC Systems and attempt to facilitate, at a minimum, the common GRC functions, discussed earlier.
Some systems attempt to go beyond the basic requirements. Far too often, systems that extend themselves to specialize in one area of GRC fail to adequately address most other areas of GRC. For example, a system that tries to specialize in the details of Cyber Security will rarely concern itself with things like Regulations Tracking, detailed Manufacturing Controls, or Data Center Security. For these reasons, the recommendation is that whatever system(s) you select and put in place for GRC should, at a minimum, focus on providing capabilities that facilitate and support the higher level logistical functions that are common to all GRC implementations (listed above).
Common GRC Mistakes
Enterprises that attempt to implement GRC makes some common mistakes that you might want to familiarize yourself with.
- One of the biggest mistakes made by GRC Governing Bodies is the attempt to control or establish controls for far more than what actually needs to be controlled. This almost always results in far more work than needs to be performed, more complex solutions, and wasted critical funds that could be spent elsewhere.
- Another common mistake made when implement GRC is to populate the GRC Committee with participants who are not signature-authority leaders. Signature-authority is the term used to describe people within the organization who have the true power of securing and directing resources (e.g. finances, humans, systems, etc.).
- Another common mistake is to not implement a federated control model for GRC. It is impossible for a small group of people to control all GRC related items across the enterprise without federated support from people working in other areas of the enterprise. A federated control model allows the GRC committee to work with clearly identified roles that exist in critical areas of the enterprise.
- A common mistake is to impose GRC overhead on too many groups, treating more groups or organizations like GRC Control Groups. This can lead to a tremendous amount of waste in time, efforts, and funds.
- A big mistake is to not institute random internal audits of critical GRC areas. Random audits should not disrupt critical operations but should be used as a means to 1) make sure Control Groups know what they need to control and 2) that they’re accurately doing so and 3) that they are constantly aware of and on top of their responsibilities.
- Finally, one of the most common mistakes made when implementing GRC is to not make GRC control responsibilities a clear and accountable part of the job descriptions for those people involved in all areas of GRC. If people do not know their responsibilities and what they are accountable for, the GRC Governing Body will have a disconnect from what is happening in other areas of the enterprise. This will lead to difficulties in collecting and providing GRC related evidence, when necessary.