GRC - governance vs risk vs compliance

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.

Integrated Controls Management - brakes on a car


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.

Integrated Controls Management (ICM) = "How To GRC Playbook"

The premise of Integrated Controls Management (ICM) is that controls are central to cybersecurity and privacy operations, as well as the overall business rhythm of an organization. ICM takes a different approach from the traditional definition of Governance, Risk Management and Compliance (GRC) and/or Integrated Risk Management (IRM), since ICM is controls-centric, where controls are viewed as the nexus, or central pivoting point, for an organization’s cybersecurity and privacy operations.

The premise is that controls are central to cybersecurity and privacy operations, as well as the business rhythms of the organization. Without properly defining controls 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" enhances risk management discussions.

Integrated controls management - cybersecurity controls 

OCEG defines GRC as, “GRC is the integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty and act with integrity,” while Gartner jointly defines GRC/IRM as, "a set of practices and processes supported by a risk-aware culture and enabling technologies, that improves decision making and performance through an integrated view of how well an organization manages its unique set of risks." ComplianceForge and Secure Controls Framework (SCF), the developers of the ICM model, define ICM as, “a holistic, technology-agnostic approach to cybersecurity and data protection controls to identify, implement and manage secure and compliant practices, covering an organization’s people, processes, technology and data, regardless of how or where data is stored, processed and/or transmitted.

ICM is designed to proactively address the strategic, operational and tactical nature of operating an organization’s cybersecurity and privacy program at the control level. ICM is designed to address both internal controls, as well as the broader concept of Cybersecurity Supply Chain Risk Management (C-SCRM).

Integrated Controls Management - cover

[overview can be downloaded from

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:

GRC Always Begins With Defining What It Means To Be “Secure & Compliant” 

Unlike GRC/IRM, ICM specifically focuses on the need to understand and clarify the difference between "compliant" versus "secure" since that is necessary to have coherent risk management discussions. To assist in this process, ICM helps an organization categorize its applicable controls according to “must have” vs “nice to have” requirements:

Secure and compliant operations exist when both MCR and DSR are implemented and properly governed:

cybersecurity compliant vs secure | compliance vs security

Integrated Controls Management Utilizes A Principles-Based Approach To Operationalizing The Model

There are eight (8) principles associated with ICM:

  1. Establish Context
  2. Define Applicable Controls
  3. Assign Maturity-Based Criteria
  4. Publish Policies, Standards & Procedures
  5. Assign Stakeholder Accountability
  6. Maintain Situational Awareness
  7. Manage Risk
  8. Evolve Processes

ComplianceForge has simplified the concept of "how to GRC" in the following downloadable diagram to demonstrate the unique nature of these components, as well as the dependencies that exist:

Integrated Controls Management (ICM) – Overlaid On Integrated Cybersecurity Governance Model (ICGM) 

integrated controls management - plan do check act

[graphic can be downloaded from

Principle 1: Establish Context

To build and maintain efficient and effective operations, a cybersecurity & privacy program must have a hierarchical vision, mission and strategy that directly supports the organization’s broader strategic objectives and business processes. This process of establishing context involves identifying all applicable external compliance requirements (e.g., laws, regulations and contractual obligations), as well as internal directives (e.g., Board of Directors, corporate policies, etc.). This is a due diligence element of the cybersecurity and privacy program.

cybersecurity supply chain risk management c-scrm nist 800-161

Principle 2: Define Applicable Controls

A tailored control set cybersecurity and data protection controls must exist. This control set needs to be made of Minimum Compliance Criteria (MCC) and Discretionary Security Requirements (DSR). This blend of “must have” and “nice to have” requirements establish an organization’s tailored control set to ensure both secure practices and compliance.

Principle 3: Assign Maturity-Based Criteria

The cybersecurity & privacy program must assign maturity targets to define organization-specific “what right looks like” for controls. This establishes attainable criteria for people, processes and technology requirements. Tailored maturity level criteria can be used to plan for, budget for and assess against. Maturity targets should support the organization’s need for operational resiliency.

Principle 4: Publish Policies, Standards & Procedures

Documentation must exist, otherwise an organization’s cybersecurity and data protection practices are unenforceable. Formalizing organization-specific requirements via policies and standards are necessary to operationalize controls. Stakeholders utilize those prescriptive requirements to develop Standardized Operating Procedures (SOP) that enable Individual Contributors (IC) to execute those controls. Policies, standards and procedures provides evidence of due diligence that the organization identified and implemented reasonable steps to address its applicable requirements.

Principle 5: Assign Stakeholder Accountability

Controls must be assigned to stakeholders to ensure accountability (e.g., business units, teams and/or individuals). These “control owners” may assign the task of executing controls to “control operators” at the IC-level. The documented execution of procedures provides evidence of due care that reasonable practices are being performed.

Principle 6: Maintain Situational Awareness

Situational awareness must involve more than merely “monitoring controls” (e.g., metrics). While metrics are a point-in-time snapshot into discrete controls’ performance, the broader view of metrics leads to a longer-term trend analysis. When properly tied in with current risk, threat and vulnerability information, this insight provides “situational awareness” that is necessary for organizational leadership to adjust plans to operate within the organization’s risk threshold.

Principle 7: Manage Risk

Proactive risk management processes must exist across all phases of development/information/system life cycles to address confidentiality, integrity, availability and safety aspects. Risk management must address internal and external factors, including privacy and Supply Chain Risk Management (SCRM) considerations. To manage risk, it requires the organization to clearly define its risk threshold and risk management expectations.

Principle 8: Evolve Processes

Cybersecurity and data protection measures must adapt and evolve to address business operations and the evolving threat landscape. This requires the adoption of a Plan, Do, Check & Act (PDCA) approach (Deming Cycle) to ensure the organization proactively identifies its requirements, implements appropriate protections, maintains situational awareness to detect incidents, operates a viable capability to respond to incidents and can sustain key business operations, if an incident occurs.

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:

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.

GRC - chicken vs egg - governance vs risk vs compliance


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:

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:

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 six (6) main parts:

  1. Policies establish management’s intent;
  2. Control Objectives identify leading practices (mapped to requirements from laws, regulations and frameworks);
  3. Standards provide quantifiable requirements;
  4. Controls identify desired conditions that are expected to be met (requirements from laws, regulations and frameworks);
  5. Procedures / Control Activities establish how tasks are performed to meet the requirements established in standards and to meet controls; and
  6. Guidelines are recommended, but not mandatory.

NIST 800-53 800-171 ISO 27001 27002 NIST CSF SCF policies standards procedures example

Risk Management

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:

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:

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):

 governance vs risk vs compliance

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:

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?

Browse Our Products

  • Digital Security Program (DSP)

    Digital Security Program (DSP) - SCF Policy Template

    Secure Controls Framework (SCF)

    Secure Controls Framework (SCF) "Premium Content" - Expertise-Class Policies, Control Objectives, Standards, Guidelines, Controls & Metrics. Product Walkthrough Video This short product walkthrough video is designed to give a brief overview about...

    Choose Options
  • Cybersecurity Standardized Operating Procedures (CSOP) Template - Digital Security Program (DSP) Version

    DSP & SCF Procedures Template

    Secure Controls Framework (SCF)

    Cybersecurity Standardized Operating Procedures (CSOP)  DSP | SCF Version Product Walkthrough Video This short product walkthrough video is designed to give a brief overview about what the CSOP is to help answer common questions we receive...

    Choose Options
  • NIST 800-171 Compliance Program (NCP). This is a bundle of products that are specific to NIST 800-171 and CMMC 2.0 compliance - policies, standards, procedures, SSP & POA&M templates. Editable CMMC 2.0 Level 2 (old Level 3) policies, standards, procedures, SSP & POA&M templates. CMMC policies & standards. NIST 800-171 policies & standards.

    NIST 800-171 Compliance Program (NCP): CMMC Level 2

    ComplianceForge - NIST 800-171 & CMMC

    NIST SP 800-171 & CMMC Editable & Affordable Cybersecurity Documentation This short product walkthrough video is designed to give a brief overview about what the NCP is to help answer common questions we receive. NIST 800-171 Rev 3...

    Choose Options
  • DSP Bundle 1: DSP-CSOP

    DSP Bundle 1: Policies, Standards, Procedures & Controls

    Secure Controls Framework (SCF)

    Digital Security Plan (DSP) Bundle #1 - SCF-Aligned Policies, Standards & Procedures (25% Discount) This is a bundle that includes the following two (2) ComplianceForge products that are focused on operationalizing the Secure Controls Framework...

    Choose Options
  • DSP Bundle 2

    DSP Bundle 2: Enhanced Digital Security Documentation

    Secure Controls Framework (SCF)

    Digital Security Plan (DSP) Bundle #2 - ENHANCED DIGITAL SECURITY (35% Discount) This is a bundle that includes the following seven (7) ComplianceForge products that are focused on operationalizing the Secure Controls Framework (SCF): Digital...

    Choose Options
  • DSP Bundle 3: Whole Enchilada

    DSP Bundle 3: Robust Digital Security Documentation

    Secure Controls Framework (SCF)

    Digital Security Plan (DSP) Bundle #3 - ROBUST DIGITAL SECURITY (45% Discount) This is a bundle that includes the following thirteen (13) ComplianceForge products that are focused on operationalizing the Secure Controls Framework (SCF): Digital...

    Choose Options

Learn More About Cybersecurity & Data Privacy