The GRC Triad as an Operating System

The system: how the three disciplines feed each other

The failure of most GRC programs starts with a structural mistake: treating governance, risk management, and compliance as three separate filing cabinets. Governance produces policies. Risk management produces a register. Compliance produces audit evidence. Three teams, three outputs, zero integration. The policies don't reference the risks. The risk register doesn't reference the controls. The audit evidence doesn't trace to either.

An integrated GRC system works differently. Risk management is the engine. It identifies what can go wrong, assesses the likelihood and impact, and determines what to do about it. Governance is the steering mechanism. It makes the decisions: which risks to treat, which to accept, what policies to enforce, how to allocate resources. Compliance is the evidence layer. It proves the decisions were implemented and the controls are working.

The system becomes powerful when three feedback loops close the cycle.

Figure 1.1: The GRC operating system. Risk management identifies threats. Governance makes decisions. Compliance produces evidence. Three feedback loops close the cycle. External inputs (incidents, regulatory changes, audit findings) feed continuous updates.

Every arrow in that diagram represents a data flow that either exists in your organization or doesn't. If the arrow from compliance back to risk management is missing, meaning audit findings and control effectiveness data never feed back into the risk register, you're running an open-loop system. The risk register degrades over time because it never receives correction signals. McKinsey's 2025 Global GRC Benchmarking Survey found that 42% of organizations say their IT and GRC systems need improvement, and 15% say they are absent or lagging entirely. The missing feedback loops explain why.

The three feedback loops

Loop 1: Risk informs governance decisions. Risk management identifies a threat (credential phishing targeting finance users, for example). The risk assessment quantifies the exposure: estimated $340,000 based on average outbound payment value. This data flows to governance, where the risk committee approves treatment: deploy anti-phishing policies, enforce phishing-resistant MFA for finance accounts, and run monthly targeted simulations. Without this loop, governance decisions are based on intuition rather than data, and budget goes to whoever argues loudest rather than wherever the risk is greatest.

Loop 2: Governance decisions produce compliance evidence. The governance decision (enforce phishing-resistant MFA) creates a control. The control produces evidence: Conditional Access policy evaluation logs, sign-in records showing MFA method used, phishing simulation results. This evidence flows to compliance, which maps it to framework requirements. The MFA enforcement satisfies ISO 27001 A.8.5 (authentication), NIST CSF PR.AA-03 (identity management), and NIS2 Article 21(2)(j) (multi-factor authentication). Without this loop, compliance evidence is collected separately from the controls that produce it, creating a manual reconciliation burden that grows with every framework.

Loop 3: Compliance evidence reassesses risk. The compliance evidence reveals that MFA enforcement is 94% across the organization but only 71% for administrative accounts in the finance department. This finding flows back to risk management, which updates the credential phishing risk: the control is partially effective, residual risk is higher than assumed. The risk committee reviews the updated assessment and authorizes a targeted remediation. Without this loop, the risk register assumes controls are working as designed. The 71% enforcement gap persists because nobody measures, and the risk score stays at the level the original treatment plan predicted.

The COSO ERM 2025 framework and the OCEG Capability Model both emphasize these feedback connections. COSO structures the loops as five components: governance and culture, strategy and objective-setting, performance, review and revision, and information/communication/reporting. OCEG calls the integrated approach "Principled Performance." The terminology differs but the principle is the same: the three disciplines produce value when connected and produce shelf-ware when separated.

Tracing a risk through the system

To make the integration concrete, trace a single risk through both models. A threat intelligence report identifies that adversary-in-the-middle credential phishing attacks against organizations in your sector have increased 340% in the past quarter.

In an integrated system, the threat intel triggers an immediate risk register update. The risk score changes from Medium to High based on sector-specific data. The impact is quantified using the average outbound payment value for the CFO's mailbox. The risk committee approves three treatments within a week: anti-phishing policies in Defender for Office 365, phishing-resistant MFA for all finance and executive accounts, and monthly targeted phishing simulations. Each control is mapped to the relevant compliance requirements. Evidence collection begins automatically from sign-in logs and simulation results. Four weeks later, the compliance evidence shows 100% enforcement for the target population. The risk score is updated to reflect the implemented controls.

In a disconnected system, the same threat intel goes to the SOC. The SOC manager mentions it in a team meeting. Nobody updates the risk register because "we already have phishing in there." No formal governance decision is made and no budget is allocated. An analyst enables the anti-phishing policy because it seems like a good idea, but there's no mapping to the risk, no documentation, and no measurement. Six months later, the auditor asks for evidence that the organization responded to the AiTM threat. The evidence doesn't exist because the response was informal, undocumented, and unmeasured.

The difference between these two outcomes is not capability. Both organizations have the same tools, the same staff, the same threat intelligence feed. The difference is structural: whether risk data flows to governance, whether governance decisions produce documented controls, and whether control evidence flows back to risk assessment.

The integrated system produces full traceability. Every risk connects to the controls that treat it, the evidence that proves the controls work, and the framework requirements the controls satisfy. The relational diagram below shows this chain for the AiTM phishing risk:

Figure 1.2: Risk-Control-Evidence traceability for the AiTM phishing risk. Each arrow is a connection that either exists in your organization or doesn't. The dashed return arrow shows Loop 3: evidence data flowing back to reassess the original risk.

The governance decision that tests the system

The triad diagram shows how data flows. What it doesn't show is what happens when the flows collide at a governance decision point. Consider the scenario every GRC practitioner eventually faces: the CEO requests an MFA exception.

The CEO travels internationally and finds the MFA prompt on his phone disruptive. He asks for an exception to the access control policy. Your policy says MFA is required for all users. The CEO is a user. What do you do?

This is a governance decision, not a technical one. Three options exist, and each reveals something about how the GRC system functions.

Accept the risk formally. Document the CEO's request, assess the residual risk (executive mailbox without MFA is a high-value BEC target), present the risk to the CEO for formal acceptance, and maintain the exception in the risk register with a review date. This is valid governance. The CEO has authority to accept risk for his own account. But the exception creates three downstream problems: the SOC 2 auditor will question whether access control is "consistently applied," the ISO 27001 auditor will assess whether residual risk is within tolerance, and every other executive will request the same accommodation. Within six months, you have 15 MFA exceptions for your highest-value targets.

Offer a technical alternative. Investigate phishing-resistant options that address the UX concern: a FIDO2 security key (tap to authenticate, no app required), a passkey enrolled on the tablet, or certificate-based authentication. Present the CEO with options that satisfy the security requirement without the friction he objects to. If a viable alternative exists, the exception is unnecessary and the risk is avoided entirely.

Deny the request outright. The policy says MFA is required. The CEO is a user. No exceptions. This is technically correct and organizationally destructive. The CEO overrides you because he has the authority. You now have an undocumented exception (worse than option one) and a damaged relationship with the most powerful stakeholder in the organization. Governance authority operates through influence, not decree.

The correct first response is the technical alternative. It addresses the CEO's actual concern (UX friction) without creating a control gap. A FIDO2 key costs $25 and provides stronger authentication than app-based MFA. If the CEO accepts the alternative, the policy is satisfied, the risk is avoided, and no exception is needed. This is governance in practice: managing risk through decisions, not enforcing rules through confrontation.

Three maturity levels

Before you can build the right program, you need to know where you're starting. The maturity model below provides the diagnostic.

Most organizations score between 5 and 9, landing in the structured range. The components exist but aren't connected. The risk register is maintained but doesn't drive policy decisions. Policies exist but aren't mapped to controls. Compliance evidence is collected but doesn't feed back into risk scores. The course modules from G2 onward build the connections that move you from structured to integrated.

If you score below 5, your priority is establishing the basic components. Complete G1-G2 for foundations, then G3-G5 to build the risk management engine. Don't attempt framework certification until the engine is running. If you score above 13, your program is already operational. Focus on Phase 4 modules: G12 for audit management, G13 for board reporting, G14 for regulatory change management.