Audits (External, Internal) , Compliance Management , Cybersecurity insurance , Governance, Risk and Compliance , Government Regulations , Industry Regulations , Risk Assessments/Management , Security Strategy, Plan, Budget What GRC Actually Controls July 24, 2026 Share By SC Media Editorial Intelligence, reviewed by Michael Tayo 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