- GRC fundamentally exists to help organizations avoid negligence with the added benefit of improved cybersecurity operating effectiveness.
- The Security, Compliance & Resilience Management System (SCRMS) model provides a 9-step "how to build a cybersecurity program" playbook.
- The Plan, Do, Check & Act (PDCA) cycle is the foundation for continuous GRC improvement.
- Understanding the difference between "compliant" vs "secure" (MCR vs DSR) is critical for coherent risk management.
- In the GRC debate, Compliance comes first (identifying obligations), then Governance (policies/standards), then Risk Management (ongoing assessment).
Why Does GRC Matter?
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, cybersecurity, and privacy operating effectiveness.
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.
Security, Compliance & Resilience Management System
ComplianceForge focuses on the Security, Compliance & Resilience Management System (SCRMS) approach, since GRC is a controls-centric activity. Viewing controls as the central nexus for cybersecurity and data protection operations can help an organization be secure, compliant and resilient. The PDCA approach (Deming Cycle) enables the GRC function to continuously evaluate risks, threats, and performance trends.
Plan
Define policies, standards, and controls. Influence technology purchases to address defined needs.
Do
Implement controls, the "security glue." Develop and execute procedures (control activities).
Check
Achieve situational awareness through metrics reporting and audit/assessment results review.
Act
Risk management: address real deficiencies and possible threats to the organization.
The Security, Compliance & Resilience Management System (SCRMS) is a free guide. It is meant to utilized as a holistic, technology-agnostic framework for an entity to design, implement and maintain secure, compliant and resilient capabilities, covering an organization’s People, Processes, Technology, Data and Facilities (PPTDF), regardless of how or where data is stored, processed and/or transmitted.
The SCRMS is not a “one-size-fits-all” playbook. It is designed to be adopted and tailored to the unique size, resources, and risk circumstances of each organization. a
- Establish Context. Establishing context is both a due diligence and due care element of a cybersecurity program, since context changes with time. Considerations include: mission/vision/strategy; statutory, regulatory, and contractual requirements; fiscal constraints; organizational structure; applicable geographic-specific requirements; and internal and external stakeholder expectations.
- Identify Applicable Controls. A tailored set of cybersecurity and data protection controls must exist for a SCRMS implementation. This control set must be tailored to the organization’s unique requirements, combining Minimum Compliance Requirements (MCR) and Discretionary Security Requirements (DSR). This blend of “must have” and “nice to have” establishes the organization’s tailored control set.
- Define Maturity Expectations. The organization must define maturity expectations for its cybersecurity and data protection controls. From the SCRMS perspective, maturity expectations define entity-specific “what right looks like” for control implementation and ongoing operation. These maturity-based criteria apply across People, Processes, Technologies, Data, and Facilities (PPTDF) and directly support the organization’s security, compliance, and resilience goals.
- Publish Governance Documentation. Governance documentation is the written foundation of a cybersecurity program. This includes policies, standards, procedures, guidelines, and plans. Without published documentation, controls cannot be consistently applied, audited, or enforced. The SCF provides a direct mapping between controls and the governance documentation required to support them.
- Assign Stakeholder Accountability. Every control must have an owner. Accountability structures ensure that cybersecurity responsibilities are clearly assigned to specific roles across the organization, not just the security team. This includes executives (risk ownership), managers (policy enforcement), and operational staff (procedure execution). Undefined accountability is one of the most common root causes of control failures.
- Prioritize Capabilities According to Risk. Not all controls carry equal risk weight. Organizations with finite resources must prioritize implementation based on risk exposure, compliance criticality, and threat relevance. The SCRMS provides guidance for risk-based prioritization so that the most impactful controls are implemented first, ensuring early risk reduction even before a complete control set is in place.
- Maintain Situational Awareness. Situational awareness is achieved through continuous monitoring, metrics collection, and periodic assessments. This principle covers logging, monitoring, alerting, and audit programs. Without situational awareness, organizations cannot detect incidents, measure control effectiveness, or demonstrate compliance. The SCRMS aligns this principle directly to the Check phase of the PDCA cycle.
- Manage Risk. Risk management is the engine of the SCRMS Act phase. It encompasses: identifying and treating current deficiencies, assessing emerging threats and vulnerabilities, making risk acceptance decisions, tracking remediation, and reporting risk status to stakeholders. The SCF’s risk management controls (GOV, RSK domains) provide the specific control requirements for building a functional risk management function.
- Evolve Processes. The SCRMS is a living system. Cybersecurity threats, business contexts, and regulatory landscapes all change over time. Organizations must build continuous improvement into the SCRMS lifecycle by reviewing the program periodically, updating controls and governance documentation, reassessing risk, and incorporating lessons learned from incidents and audits into the next planning cycle.
"Compliant" vs "Secure"
Secure and compliant operations exist when both Minimum Compliance Requirements (MCR) and Discretionary Security Requirements (DSR) are implemented and properly governed:
Minimum Compliance Requirements (MCR)
The absolute minimum requirements to comply with applicable laws, regulations, and contracts. Primarily externally influenced. MCR should never imply adequacy for secure practices, as they are merely compliance-related.
Discretionary Security Requirements (DSR)
Tied to the organization's risk appetite. These represent "above and beyond" MCR. The organization self-identifies additional controls to address voluntary practices or internal findings. This is where organizations achieve improved efficiency and automation.
The GRC Debate: Governance vs Compliance vs Risk
There is a logical order to GRC processes. Compliance identifies obligations, Governance builds the framework, and Risk Management provides ongoing assessment.
1. Compliance (First)
Identifies applicable statutory, regulatory, and contractual obligations. The "source of truth" that informs Governance about which controls must exist. Defines the organization's Minimum Security Requirements (MSR).
2. Governance (Second)
Develops policies and standards to meet compliance obligations. Assigns ownership of controls to applicable stakeholders via RASCI charts. Stakeholders develop SOPs to implement controls.
3. Risk Management (Third)
Serves as the "canary in the coal mine" to identify non-compliance. Ongoing risk assessments occur more frequently than audits. Determines risk treatment: reduce, avoid, transfer, or accept.
GRC is a process, not a tool. Automating bad processes only makes them faster. If your GRC tools have little tie-in to actual cybersecurity controls, you may have a "garbage in = garbage out" problem.
GRC Effort Prioritization
What Is The Order Of Precedence For GRC?
For an organization that wants to establish a GRC program, it is important to note that these fundamental GRC function components must be implemented in order of precedence to get the process properly focused. You can download the graphic shown below here:
- COMPLIANCE. GRC practices start with the need to first identify applicable statutory, regulatory and contractual obligations that the organization mustcomply with, as well as internal business requirements (e.g., Board of Director directives). This is a compliance function. This process of identifying statutory, regulatory and contractual obligations addresses duediligence expectations for an organization to identify what is reasonably required to address its applicable external compliance obligations from a cybersecurityand data protection perspective.
- GOVERNANCE. Once the controls are defined to meet the organization's specific needs (e.g., MCR + DSR), the governance function (1) develops policies and standards to meet those compliance obligations; and (2) assigns ownership of those controls to the applicable stakeholders involved in the affected business processes.
- RISK. While risk management activities follow compliance and governance prerequisites, risk management is integral in maintaining situational awareness for the organization to remain both secure and compliant. These risk management activities addresses both due diligence and due care obligations to identify, assess and remediate control deficiencies.