Governance, Risk Management & Compliance (GRC) Content - Policies, Standards & Procedures

At ComplianceForge, we've been writing documentation and supporting GRC initiatives since 2005. We have cybersecurity & data protection policies, standards, procedures and more that are specifically designed to be imported in and used by GRC solutions. 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.

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.

 

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

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 GRC process beings with planning. This planning will define the policies, standards and controls for the organization. It will also directly influence the tools and services that an organization purchases, since technology purchases should address needs that are defined by policies and standards.
• Do. Arguably, this is the most important section for cybersecurity and privacy practitioners. Controls are the “security glue” that make processes, applications, systems and services secure. Procedures (also referred to as control activities) are the processes how the controls are actually implemented and performed. The Secure Controls Framework (SCF) can be an excellent starting point for a control set if your organization lacks a comprehensive set of cybersecurity and privacy controls.
• Check. In simple terms, this is situational awareness. Situational awareness is only achieved through reporting through metrics and reviewing the results of audits/assessment.
• Act. This is essentially risk management, which is an encompassing area that deals with addressing two main concepts (1) real deficiencies that currently exist and (2) possible threats to the organization.

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:

• Minimum Compliance Requirements (MCR) are the absolute minimum requirements that must be addressed to comply with applicable laws, regulations and contracts.
• Discretionary Security Requirements (DSR) are tied to the organization’s risk appetite since DSR are “above and beyond” MCR, 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.

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

• MCR are primarily externally-influenced, based on industry, government, state and local regulations. MCR should never imply adequacy for secure practices and data protection, since they are merely compliance-related.
• DSR are primarily internally-influenced, based on the organization’s respective industry and risk tolerance. While MCR establish the foundational floor that must be adhered to, DSR are where organizations often achieve improved efficiency, automation and enhanced 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) 

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.

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 Requirements (MCR) 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:

• 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.

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., MCR + 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.

Governance

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 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.

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:

• 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., MCR + 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?

• SCF Licensed Content Provider

  ComplianceForge is very pleased to announce it is now a Secure Controls Framework Licensed Cont...

• What Is NIST CSF?

  The NIST Cybersecurity Framework (NIST CSF) is commonly used “cybersecurity best practice” for organ...

• Supply Chain Risk Management (SCRM) Plan

  Cybersecurity Supply Chain Risk Management (C-SCRM) is the process of identifying, assessing and mit...

• Efficient CMMC Scoping

  Determining the scope of controls (e.g., assessment boundary) is different than determining control...

---