What It Is Not
GRC is commonly described as frameworks, policies, risk registers, and audit programs. These are things GRC programs produce. They are not what GRC controls.
A framework maps the organization's controls to NIST CSF or ISO 27001 requirements. A policy documents what the control is supposed to do. A risk register lists the risks the organization has identified. An audit program generates findings.
None of these activities, by themselves, proves that controls operate — that the control ran, did what it was designed to do, and produced the protection it was supposed to provide during the period in question.
The confusion is consequential. Organizations that mistake documentation for assurance discover the gap in specific, predictable contexts: the audit finding that reveals a documented access control wasn't enforced. The regulatory inquiry that reveals the privacy control mapped to GDPR wasn't operating during the breach period. The enterprise deal that stalls because the customer's vendor questionnaire requires operating evidence the security team cannot produce. The insurance claim where the forensic investigator cannot verify that the security program ran as the policy application represented.
These are assurance failures. In each case the underlying control may be owned by another team — but GRC owned the chain that was supposed to surface whether that control was operating, and to produce evidence of it before the moment of need. The documentation existed. The evidence of operation did not. As the later section makes explicit, GRC does not fix or operate the control; its accountability is for the evidence-and-assurance chain that should have caught the gap.
What GRC Actually Controls
GRC controls the chain from control requirement to defensible decision: the discipline that converts documented controls into proven controls, and converts proven controls into risk statements leaders can act on.
That chain has five links:
Control requirement: What the organization must do — drawn from regulatory obligations, contractual commitments, risk assessments, and framework adoption decisions. A control requirement specifies an outcome: access to production systems is limited to authorized users. It does not specify whether that outcome is currently being achieved.
Evidence: Proof that the control is operating as designed, continuously, not only when it was configured. Evidence is distinct from documentation. Documentation says the control should work. Evidence shows it is working. The difference is testable: can the organization demonstrate control operation during the last quarter, at any point during that quarter, with artifact support?
Assurance: The evaluation of evidence against the quality standard — does this evidence demonstrate that the control operated effectively, continuously, with exceptions properly identified and managed? Assurance is not a binary pass/fail. It is a qualified position: this control is operating at this level, with this exception, with this evidence quality. The qualification matters because downstream decisions depend on the accuracy of the assurance position.
Risk statement: A translation of the assurance position into language that enables decision. "Control X is operating effectively with one exception: privileged access review was completed for 94% of accounts in Q4, with 6% overdue by an average of 12 days" is a risk statement. It tells a leader what is true, what is not, and what the risk implication is. "We have an access governance control" is not a risk statement — it describes a control's existence, not its operating reality.
Decision: The leadership action that the risk statement informs. Accept the residual risk with documented accountability. Invest in remediation to close the exception. Escalate to the board because the residual risk exceeds defined tolerance — which presumes the organization has set that tolerance against an explicit appetite. Where it has not, surfacing the absence of a defined threshold is itself a risk statement worth escalating. GRC's chain is complete when evidence produces a decision — not when it produces a report.
The Three Gaps GRC Closes
Three gaps appear in most organizations' control programs. GRC is the discipline that closes them.
Gap 1: Documented versus operating controls.A control is documented when policy, process, or system configuration specifies what should happen. A control is operating when that specification is executed consistently and evidence of execution exists. The gap between documentation and operation is common because documentation is easier to produce than evidence, and because organizations routinely audit documentation without testing operation.
The diagnostic question: for each control in the organization's control inventory, what evidence exists that the control operated continuously during the last twelve months? Not the policy document. Not the system configuration screenshot from implementation. The evidence of continuous operation.
Gap 2: Framework mapping versus assurance.A framework mapping identifies which organizational controls satisfy which framework requirements. Completing a NIST CSF mapping produces a coverage picture: the organization has controls addressing these categories and subcategories. It does not produce assurance that those controls are effective.
The mapping answers: do we have controls for these requirements? Assurance answers: are those controls working? The gap between them is the gap between audit scope and audit substance. An auditor reviews what evidence the organization can produce, not what controls the organization has mapped.
Gap 3: Risk register versus decision.A risk register documents identified risks, their probability and impact estimates, and their current status. Maintaining a risk register produces a catalog of risks the organization is aware of. It does not produce decisions about what to do about them.
The risk register answers: what risks have we identified? Decisions answer: for each identified risk, what is the organization's documented response — and who is accountable for that response? The gap is filled by risk acceptance processes that require named accountability, documented rationale, and defined re-review dates.
The Evidence Standard
Evidence is not any documentation related to a control. Evidence, as GRC requires it, is documentation that demonstrates control operation over the relevant period.
The relevant period is defined by what the downstream use requires. A SOC 2 Type II report requires evidence of control operation throughout a defined audit period — commonly three, six, or twelve months, scoped to the engagement rather than fixed at a year. (A SOC 2 Type I report, by contrast, evaluates control design at a single point in time, not operating effectiveness over a period — the textbook case of design documented, operation not yet proven, which is exactly the distinction this article turns on.) A regulatory inquiry that follows an incident may require evidence of control operation during the months preceding the incident. An insurance claim review may require evidence that controls specified in the policy application were operating continuously during the policy period.
Three evidence quality tests distinguish operating evidence from documentation:
Continuity: Does the evidence demonstrate operation across the full period, or only at a point in time?
A system configuration screenshot captures one moment. Access review completion logs for each month of the audit period demonstrate continuity.
Specificity: Does the evidence identify what was tested, by whom, when, and what the result was?
"Our access review process ran this quarter" is less specific than "access review was completed for 94% of accounts on these dates, exceptions were escalated on these dates, remediation was tracked through these dates."
Traceability: Can the evidence be traced to the control it demonstrates without requiring explanation?
An auditor reviewing the evidence without GRC team assistance should be able to determine which control the evidence supports and whether it demonstrates effective operation.
These tests sit alongside the control-testing methodology a knowledgeable auditor brings: test of design versus test of operating effectiveness (TOD/TOE), and sampling versus population testing. An automated control that runs identically every time can often justify a smaller sample than a manual control that depends on a person executing a step. The "94% of accounts" figure above is a population-level result; when evidence is sampled rather than tested at population, the sampling basis is itself part of what makes the evidence defensible.
Producing twelve monthly artifacts by hand is the burden this standard implies — and increasingly the reason organizations adopt continuous control monitoring (CCM), evidence automation, and control-as-code. These approaches generate operating evidence as a byproduct of the control running, rather than as a separate, periodic collection exercise that competes with operational work for attention.
Evidence that fails one or more of the three quality tests is documentation, not assurance evidence. GRC programs that submit documentation when auditors are looking for evidence produce findings.
What GRC Does Not Own
The technical controls themselves: IAM governance, cloud security posture management, detection engineering, application security, and data protection controls are each owned by the programs that build and operate them. GRC depends on those programs to produce controls worth evidencing. When a control is not operating, GRC identifies the gap and escalates to the program that owns the control for remediation. GRC does not fix the control.
The detailed mechanics of individual control domains: how privilege access reviews work is an IAM governance matter. How detection rules are validated is a detection engineering matter. GRC understands these controls at the level needed to assess evidence quality — it does not operate them.
Regulatory legal interpretation: when regulations are ambiguous, GRC uses legal counsel's interpretation of what they require. GRC implements the assurance program that satisfies the requirement; legal counsel determines what satisfying the requirement means.
The independent-assurance boundary. This frame deliberately holds GRC accountable for the assurance
chain — defining the evidence standard, evaluating evidence against it, and translating the result into risk statements. That is a stance, not a settled fact, and it is worth naming the alternative. The IIA's Three Lines Model places independent assurance — the objective testing of whether controls operate — with internal audit, the third line, while risk and compliance functions typically sit in the second line: oversight, framework, and risk facilitation rather than independent testing. In many organizations the second line coordinates and evaluates assurance while the third line provides the independent test. Where that boundary falls is an organizational design choice. The accountability described here — for the integrity of the evidence-to-decision chain — holds regardless of which line performs the independent test, but a mature program should be explicit about which role it is playing rather than blurring second-line evaluation with third-line independence.
The GRC Program's Accountability
The GRC program is accountable for the assurance chain — from control requirements through evidence through risk statements to decisions. It is not accountable for the quality of controls it did not design, the technical implementation of controls it did not build, or the risk decisions that leadership makes based on the risk statements GRC provides.
GRC's accountability is specific: the evidence it collects accurately represents what it represents, the assurance it provides is supported by the evidence it collected, and the risk statements it produces accurately reflect the assurance position. When GRC attests or reports that a control is operating, that position is defensible against the evidence behind it. Note the verb: formal certification of control operation belongs to independent auditors, to management assertions under SOC frameworks, or to signing officers. Internal GRC functions generally assert and report against evidence rather than certify — claiming a certification authority the function does not hold is itself the kind of imprecision that undercuts credibility. When GRC reports an exception, the exception is documented with the evidence that supports it.
That accountability — accurate evidence, defensible assurance, honest risk statements — is what makes GRC a functional program rather than a compliance theater operation.
Sources
