Practical Guidance: Governance, Risk Management & Compliance (GRC)
At ComplianceForge, we've been writing documentation and supporting GRC initiatives since 2005. The information on this page is meant to pass on logical, worthwhile concepts pertaining to Governance, Risk Management & Compliance (GRC) / Integrated Risk Management (IRM) that you can professionally benefit from. Please note that we use the terms GRC and IRM synonymously, since they essentially function the same when you look beyond marketing semantics.
GRC can be a costly and labor-intensive endeavor, so what justifies the investment? Essentially, GRC functions help avoid negligence, with the added benefit of improved IT/cyber/privacy operating effectiveness. The reality of the situation is your company invests in cybersecurity and privacy as a necessity. This necessity is driven in large part by laws, regulations and contractual requirements that it is legally-obligated to comply with. It is also driven by the desire to protect its public image from damaging acts that happen when cybersecurity and privacy practices are ignored. Regardless of the specific reason, those charged with developing, implementing and running your organization’s cybersecurity and data protection program must do so in a reasonable manner that would withstand scrutiny that could take the form of an external auditor, regulator or prosecuting attorney.
How fast would you drive your car if you didn’t have any brakes? Think about that for a moment - you would likely drive at a crawl in first gear and even then you would invariably have accidents as you bump into objects and other vehicles to slow down. Brakes on a vehicle actually allow you to drive fast, in addition to safely navigating dangers on the road!
While it is not the most flattering analogy, GRC is akin to the brakes on your car, where they enable a business’ operations to go fast and avoid catastrophic accidents. Without those "brakes", an accident is a certainty! These brakes that enable a business’ operations to stay within the guardrails are its cybersecurity policies, standards and procedures. These requirements constitute “reasonable practices” that the organization is required to implement and maintain to avoid being negligent.
GRC Is a Plan, Do, Check & Act (PDCA) Adventure – That Is A Concept That Should Be Embraced, Not Fought Against
GRC most often deals with legally-binding requirements, so it is important to understand that negligence is situationally-dependent. For example, an intoxicated driver who gets behind the wheel acting negligently. However, when sober, that same individual is a champion race car driver who is highly-skilled and would not be considered incompetent in any regard. In this example, driving intoxicated constitutes a negligent act and shows that negligence has nothing to do with being incompetent. The point is to demonstrate that an organization can employ many highly-competent personnel, but even competent people can behave in a negligent manner. GRC fundamentally exists to help an organization avoid circumstances that could be construed as negligent acts.
Considering how business practices continuously evolve, so must cybersecurity practices. The Plan, Do, Check & Act (PDCA) process enables the GRC function to continuously evaluate risks, threats and performance trends, so that the organization's leadership can take the necessary steps to minimize risk by modifying how people, processes and technology work together to keep everything both secure and operational. The PDCA approach (also referred to as the Deming Cycle) is a logical way to conceptualize how GRC works:
- Plan. The overall process beings with planning. At its core, this phase is the process of conducting due diligence. The results of this process will define necessary controls (e.g., requirements) that influence the need for policies, standards and procedures. These actions directly influence resourcing and procurement actions that range from staffing needs to tool purchases and services acquisition.
- Do. This phase is the process of conducting due care, where it is focused on the “reasonable care” necessary to properly and sufficiently conduct operations that demonstrate the absence of negligence. This is the execution of procedures – the processes that bring controls to life.
- Check. This phase can be considered maintaining situational awareness. There are several ways to maintain situation awareness and that ranges from control validation testing to audits/assessments and metrics.
- Act. This phase again brings up the concept of “reasonable care” that necessitates taking action to maintain the organization’s targeted risk tolerance threshold. This deals with addressing two main concepts (1) real deficiencies that currently exist and (2) areas of concern that may expose the organization to a threat if no action is taken.
At the heart of GRC processes are controls. Controls are the “security glue” that make processes, applications, systems and services compliant and/or secure. For a more in-depth discussion on the concept of controls, it is highly recommended to read the Integrated Controls Management (ICM) model that is essentially a “how to GRC” guidebook that covers the function of controls as the key to any GRC program. It is important to note that controls are not static, since business processes are not static. As business processes evolve, so must the applicable cybersecurity and data protection controls to ensure secure and compliant practices are properly identified and maintained. This process of defining “what right looks like” for controls is divined from determining the following:
- Minimum Compliance Criteria (MCC) are the absolute minimum requirements that must be addressed to comply with applicable laws, regulations and contracts. MCC’s are primarily externally-influenced, based on statutory, regulatory and contractual requirements. These are the “must have” controls for an organization to be considered compliant. MCC should never imply adequacy for secure practices and data protection, since MCC are merely compliance-related.
- Discretionary Security Requirements (DSR) are tied to the organization’s risk appetite since DSR are “above and beyond” MCC, where the organization self-identifies additional cybersecurity and data protection controls to address voluntary industry practices or internal requirements, such as findings from internal audits or risk assessments. DSR are primarily internally-influenced, based on the organization’s respective industry and risk tolerance. While MCC establish the foundational floor that must be adhered to, DSR are where organizations often achieve improved efficiency, automation and enhanced security.
The premise is that controls are central to cybersecurity and privacy operations, as well as the business rhythms of the organization. Without properly defining MCC and DSR thresholds, an organization’s overall cybersecurity and privacy program is placed in jeopardy as the baseline practices are not anchored to clear requirements. Furthermore, understanding and clarifying the difference between "compliant" versus "secure" (e.g., MCC vs. MCC+DSR) enhances risk management discussions.
Chicken vs Egg Debate: The Logical Order of GRC Functions
Which comes first? Governance, Risk or Compliance? This has been a hotly-debated topic since GRC was first coined nearly 20 years ago. There is a logical order to GRC processes that has to be understood to avoid siloes and an improperly scoped security program. First off, it is necessary to level-set on the terminology of what GRC functions do:
- Governance. Structures the organization’s controls to align with business goals and applicable statutory, regulatory, contractual and other obligations. Develops necessary policies and standards to ensure the proper implementation of controls.
- Risk Management. Identifies, quantifies and manages risk to information and technology assets, based on the organization’s operating model.
- Compliance. Oversight of control implementation to ensure the organization’s applicable statutory, regulatory, contractual and other obligations are adequately met. Conducts control validation testing and audits/assessments.
When establishing GRC practices, what is described below is the precedence of how (1) compliance influences (2) governance, which influences (3) risk management. This addresses the "GRC chicken vs egg" debate.
The genesis of GRC is to first identify applicable statutory, regulatory and contractual obligations that the organization must adhere to, as well as internal business requirements (e.g., Board of Director directives). This is a compliance function that identifies statutory, regulatory and contractual obligations. It is a due diligence exercise to identify what the organization is reasonably required to comply with from a cybersecurity and data protection perspective. This process involves interfacing with various Lines of Business (LOB) to understand how the organization operates, including geographic considerations. Generally, Compliance needs to work with the legal department, contracts management, physical security and other teams to gain a comprehensive understanding of compliance needs.
Compliance is the “source of truth” for statutory, regulatory and contractual obligations. With that knowledge, Compliance informs Governance about the controls that apply to applicable laws, regulations and frameworks, so that Governance can determine the appropriate policies and standards that must exist. Compliance may identify requirements to adhere to a specific industry framework (e.g., NIST CSF, ISO 27002, NIST 800-53, etc.), but organizations are usually able to pick the framework that best fits their needs on their own. This is often where various compliance obligations exceeds what a single framework can address, so the organization has to leverage some form of metaframework (e.g., framework of frameworks).
Compliance defines the controls necessary to meet the organization’s specific needs (e.g., MCC + DSR) and publishes one or more control sets (e.g., specific to a project/contract/law/regulation or organization-wide controls). This control set(s) can be considered an organization's Minimum Security Requirements (MSR) that will be used:
- By the Governance team to develop appropriate policies, standards and other information (e.g., program-level guidance, CONOPS documents, etc.; and
- By the Risk Management team to assess risk.
Since not all controls are weighted equally, it is vitally important that personnel who represent the Risk Management function are involved in developing an assigned weight for each control (e.g., the presence of a fully-patched border firewall should be considered a more important control than end user awareness posters). This weighting of cybersecurity and data protection controls is necessary to ensure the results of risk assessments accurate support the intent of the organization's risk tolerance threshold. That threshold is meant to establish a benchmark for defining acceptable and unacceptable risk.
Based on these controls, Governance has a few key functions:
- Develop policies and standards to meet those compliance obligations (defined by applicable control objectives); and
- Assign ownership of those controls to the applicable stakeholders involved in the affected business processes. This process often requires a documented Responsibility, Accountability, Supportive, Consulted, and Informed (RASCI) chart to ensure the organizational model supports effective implementation and oversight of the assigned controls.
Personnel representing the Governance function must work directly with the stakeholders (e.g., control owners and control operators) who are directly responsible for implementing and operating their assigned cybersecurity and data protection controls. Those stakeholders are expected to develop and operate Standardized Operating Procedures (SOP) to ensure control implementation is performed according to the company’s performance requirements, as established in the organization’s cybersecurity and data protection standards. The operation of those SOPs generates evidence of due care that reasonable practices are in place and operating accordingly. Generating deliverables is an expected output from executing procedures.
The development and implementation of the policies and standards is evidence of due diligence that the organization's compliance obligations are designed to address applicable administrative, technical and physical security controls. It is important to ensure that policies and standards document what the organization is doing, as the policies and standards are often the mechanisms by which outside regulators measure implementation and maturity of the control. Cybersecurity and data protection documentation is generally comprised of five (5) core components:
- Policies are established by the organization’s corporate leadership establishes “management’s intent” for cybersecurity and data protection requirements that are necessary to support the organization’s overall strategy and mission;
- Control Objectives identify the technical, administrative and physical protections that are generally tied to a law, regulation, industry framework or contractual obligation;
- Standards provide organization-specific, quantifiable requirements for cybersecurity and data protection;
- Procedures (also known as Control Activities) establish the defined practices or steps that are performed to meet to implement standards and satisfy controls / control objectives; and
- Guidelines are additional guidance that is recommended, but not mandatory.
From a trickle-down perspective, while Risk Management logically follows both Compliance and Governance functions in establishing a GRC program, Risk Management is crucial for the organization to maintain situational awareness and remain both secure and compliant. Risk Management serves as the primary "canary in the coal mine" to identify instances of non-compliance that lead to the improper management of risks and exposure of the organization to threats, since ongoing risk assessments generally occur more frequently than internal/external audits that Compliance may oversee.
Risk Management activities addresses both due diligence and due care obligations to identify, assess and remediate control deficiencies:
- Risk Management must align with Governance practices for exception management (e.g., compensating controls).
- Compliance must evaluate findings from risk assessments and audits/assessments (both internal and external) to determine if adjustments to the organization’s cybersecurity and data protection controls (e.g., MCC + DSR) are necessary, based on business process changes, technology advancements and/or an evolution of the organization's risk threshold.
While Risk Management personnel do not perform the actual remediation actions (that is the responsibility of the control owner), Risk Management assists in determining the appropriate risk treatment options:
- Reduce the risk to an acceptable level;
- Avoid the risk;
- Transfer the risk to another party; or
- Accept the risk.
One key consideration for GRC, especially Risk Management, is that the appropriate level of organizational management makes the risk management decision. This is why risks need to be ranked, so that the appropriate levels of management can be designated as "approved authorities" to make a risk treatment determination. For example, a project manager should not be able to accept a "high risk" that should be made by a VP or some other executive. By formally-assigning risk to individuals and requiring those in managerial roles to own their risk management decisions, it can help the organization maintain its target risk threshold.
These GRC processes can be visualized in the diagram shown below that depicts the interrelated nature of GRC functions (click on image for a PDF):
If GRC Is Not Documented, It Doesn’t Exist
Once a GRC program is implemented, it requires regular and on-going reassessment of Governance, Risk Management and Compliance activities to maintain both an appropriate balance between these processes and effective operations. Similar to a three-legged stool, if one leg is too short or too long, the program will be unbalanced, wobble and not operate as needed. However, the greatest threat to GRC is organizational leadership, since it requires strong and active support of senior leaders to ensure secure and compliant practices are implemented and maintained. This is where there are some positive and negative aspects to documentation, depending on what side of the argument choose to defend. In reality, documentation is neither "good" nor "bad" since it merely exists to tell a story. However, you can see below how certain stakeholders could think documentations is "good" or "bad" based on their position:
- The ”bad” part of documenting GRC practices, is that it is not at all uncommon to hear of situations where cybersecurity practitioners are instructed to leave things off risk registers, not put things in email for fear of eDiscovery, etc. Foremost, that is an abysmal failure in leadership that should either be reported or you should seriously consider changing employment, since that type of shadow governance is both unethical and will lead to root issues never being resolved. GRC exists to “fix the puzzle” so deficiencies must be documented in order for the appropriate management function to evaluate the risk and determine the appropriate next steps. If you fail to do that harder right, then you are part of the problem.
- The ”good” part of documenting GRC practices is having appropriate evidence of due diligence and due care. This can be your “get out of jail free card” if an incident occurs and fingers get pointed for where blame should be assigned. GRC should never “own” risk, since when GRC is properly implemented, the Governance function identifies and assigns control ownership to the appropriate stakeholders. By documenting findings and elevating risk management decisions to the appropriate level, you are part of the solution and are fulfilling the intent of what you are paid to accomplish.
Garbage In = Garbage Out (GIGO)
There are a lot of wonderful tools to help automate GRC functions, but it is immensely important to understand that GRC itself is a process. You cannot reasonably expect a GRC solution to dictate what your processes are going to be – those tools exist to automate your existing processes, so if you have bad processes today, automating that will only makes those bad practices faster. This is the “garbage in = garbage out” issue that plagues many GRC implementations.
GIGO is especially true with Risk Management. This often exists in GRC tools, but it is especially true for those using Commercial Off The Shelf (COTS) risk management tools. The reason for this is the risk catalog in COTS tools often have little to no tie-in to the organization’s actual cybersecurity and privacy controls, let alone its policies and standards. This often leads to Risk Management teams "going rogue" making up their own risks that have no legitimate tie in - it just looks impressive and analysts are kept busy. This is where removing siloes and avoiding working in a vacuum is critical, since Risk Management decisions must be directly tied to controls. For example, an organization that is basely implementing policies and standards to align with the NIST Cybersecurity Framework (NIST CSF) that has a vendor risk questionnaire that far exceeds NIST CSF by a few hundred controls. If the risk questions are appropriate, that could indicate that Compliance is incorrect with its assessment of needs for security and privacy controls. However, we most often see this with Risk Management teams going rogue and simply making things up, since it makes an impressive list of risk questions to ask vendors.
GRC Is A Puzzle So Please Be Part of The Solution
Ask yourself one question: If there was a major data breach today and all eyes focused on your company, when the dust settles and root causes are investigated, would your company’s leadership and its technology stakeholders be considered negligent for failing to implement “reasonable” security and privacy practices? Now, as a GRC professional, look at your specific role and the responsibilities you have for helping keep data and technology secure. Are you part of the solution or the problem?
We want to help you be part of the solution! Contact us if you have any GRC-related questions that we can help answer?