Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

03.01 What is Governance?

Governance is the discipline that decides who decides — the policies, the approval thresholds, and the forum where the organization formally accepts risks and authorizes controls. Here's how the discipline works and how SimpleRisk implements it.

Why this matters

Governance is the part of GRC where the organization decides how it makes decisions. It's the policies that say what's allowed, the approval thresholds that say who can authorize what, the committee charters that say which forum carries which decision, and the documented record of "this is how we do things around here." Risk management surfaces the things that could go wrong; compliance proves the controls operate; governance is what closes the loop by giving the program the authority to act on what risk and compliance produce.

The trap is treating governance as bureaucracy. A policy nobody reads, an approval workflow nobody follows, a committee that meets quarterly without an agenda — these aren't governance, they're paperwork. Real governance is the part of the program that actually moves decisions: a vendor request goes through review by criteria the policy specifies and lands a yes or a no with a recorded rationale; a risk above tolerance gets formally accepted (with a recorded justification) or treated (with a recorded plan); a control that's persistently failing gets attention because the governance forum sees the failure trend and demands the conversation. Without that, risk and compliance produce a queue of unmade decisions that nobody owns.

The other thing worth knowing: governance is the discipline that scales worst when it's distributed by accident. A program where "we'll figure it out as we go" is the operating model produces inconsistent decisions, drift between what the policy says and what the practice does, and a brittle audit conversation. The discipline of writing the policies down, recording the exceptions, scheduling the review cadence, and forcing the governance forum to actually meet is what separates a program that works from one that's improvising under pressure.

How frameworks describe this

Governance is treated as foundational across the major frameworks, but the depth of treatment varies considerably.

  • COSO Enterprise Risk Management places Governance and Culture as its first component, ahead of strategy, performance, and review. The COSO framing is the most boardroom-oriented — governance is the soil the rest of the program grows in, with explicit emphasis on board oversight, organizational structure, defining a desired culture, demonstrating commitment to core values, and attracting/developing/retaining capable individuals. COSO's view is that governance is mostly about the human and structural conditions for the program to work, not about the documents the program produces.
  • NIST Cybersecurity Framework (CSF) v2.0 added Govern as its first function in the February 2024 update, on top of the original five-function v1.1 (Identify, Protect, Detect, Respond, Recover). The Govern function covers organizational context, risk management strategy, supply-chain risk management, roles and responsibilities, policies, and oversight. The addition is significant: pre-v2.0 CSF treated governance implicitly through the other functions; v2.0 makes it explicit and elevates it to the same level as the operational functions.
  • ISO/IEC 27001 clauses 5 (Leadership) and 9 (Performance evaluation) carry the governance discipline through the management-system requirements. Clause 5 is explicit about top management commitment, the information security policy, and assignment of organizational roles; clause 9 covers the management review cycle that closes the governance loop. The ISO model treats governance as the requirements of the ISMS, not as a separate component.
  • NIST SP 800-53 doesn't have a "governance" family per se, but its PM (Program Management) family contains the controls that operationalize governance: PM-1 (Information Security Program Plan), PM-2 (Senior Information Security Officer), PM-9 (Risk Management Strategy), PM-11 (Mission/Business Process Definition), and others. Programs running 800-53 implement governance through PM, even when they don't call it that.

The takeaway across all four: governance isn't an optional layer on top of risk and compliance. It's the layer that makes risk and compliance produce decisions instead of just producing data. Frameworks vary on how prominently they call it out, but they all assume it's there.

How SimpleRisk implements this

SimpleRisk's governance module surfaces three concrete capabilities under /governance/, each with its own page and its own permission set:

Policies and documents live at /governance/documentation.php. The page manages the policy library — the documents that define what the organization expects of itself and the controls that flow from those expectations. SimpleRisk supports four document types (Policies, Standards, Procedures, Guidelines) corresponding to the standard governance hierarchy: policies set direction, standards specify requirements, procedures describe execution, guidelines suggest practice. Each document carries an owner, an approver, an approval date, a review frequency, a next-review date, and links to the controls it justifies. Documents can be hierarchical (a parent policy with child standards) and can be linked to controls in the compliance module so the governance and compliance sides stay aligned. The full walk-through is in Managing Policies and Documents.

Exceptions live at /governance/document_exceptions.php. An exception is a formally-recorded deviation from a policy or a control — a system that doesn't meet the policy's encryption requirement, a vendor that doesn't have the SOC 2 the policy requires, a control that can't be tested because the underlying environment is being decommissioned. SimpleRisk supports two exception types (Policy Exceptions and Control Exceptions) with a built-in approval workflow: an exception is created, an approver reviews it, the exception either gets approved (with an expiration date) or stays unapproved. Approved exceptions have a finite lifespan; the next-review date drives a renewal cadence so exceptions don't quietly become permanent. The workflow is in Exceptions Management.

Projects live at /management/prioritize_planning.php, the project-prioritization page from the Risk Management chapter. Projects in SimpleRisk are containers that group risks together for treatment-cycle work and program-level rollup. A project can hold any number of risks; risks are assigned to projects via drag-and-drop or via the per-risk edit form. SimpleRisk uses the same projects entity for what some organizations call "projects" and what others call "programs" — there's no separate Program entity, just projects with different statuses (Active, On Hold, Completed, Canceled). The walk-through is in Projects and Programs.

The three capabilities feed each other. A new policy goes into the document library; the controls that implement it get linked to the document; exceptions get raised against the policy or the controls when reality diverges from the policy as written; risks that exceed tolerance get grouped into projects for treatment; the governance forum reviews the policies on cadence, the exceptions on cadence, and the project rollups on cadence. The forum is the human layer SimpleRisk doesn't directly model — what SimpleRisk does is keep the data the forum needs current and visible.

Common pitfalls

A handful of patterns recur when programs operationalize governance.

  • Policy without enforcement. A policy library full of documents nobody references and nobody enforces is governance theater, not governance. The fix isn't a stricter policy; it's an exception process and a control test that catches the gap. A policy that says "no shared admin accounts" without a control that audits for shared accounts and an exception process for the cases where shared accounts are unavoidable produces a security posture that says one thing and does another. Policies without enforcement are worse than no policies because they make the program look mature on paper without producing the underlying behavior.

  • Exception process used as a workaround. When the exception process is too easy to use, it becomes the default path: instead of meeting the policy, teams file an exception. Six months later the exception register is hundreds of items long and the policy is meaningless. The fix is to make the exception path appropriately frictioned (meaningful approval criteria, real expiration dates, mandatory renewal review) so that filing an exception is a real choice rather than a routine workaround.

  • The governance forum that doesn't actually meet. A risk committee that's chartered but cancels three of every four meetings isn't a governance forum; it's a calendar entry. The decisions the forum is supposed to make accumulate as a queue the security team carries on its own, which produces decisions made by whoever happens to be available rather than decisions made by the people the program designated. Schedule the forum, hold it, and produce minutes — the discipline is what makes the rest of the model work.

  • Owners who don't own. A document with an "owner" field set to a person who doesn't know the document exists isn't owned in any meaningful sense. The owner is the person responsible for the document being current, the policy being followed, and the exceptions being reasonable. Assigning owners as a checkbox rather than as a recorded accountability produces a document library where nothing is actually being maintained. Pick owners who know they own the document; tell them when the next review is due.

  • Approval as rubber stamp. An exception process where every request is approved without serious review is functionally no process at all. A real approval requires evaluating the justification, the proposed expiration, and the residual risk; when those evaluations are skipped, the approval is a record without a decision. The first sign of rubber-stamp approval: the exception register is growing and the rejection rate is zero. Calibrate the bar by occasionally rejecting exceptions that don't meet it; a rejection rate of zero is suspicious.

  • No connection between governance and compliance. A document library that doesn't link to the controls it justifies, and a control framework that doesn't reference the policies it implements, produces a governance-and-compliance pair that operates independently. Auditors notice when the policy says X and the control catalog implements Y. SimpleRisk's document_to_control mapping is the bridge; populate it, and the governance and compliance sides stay aligned automatically. See Managing Policies and Documents for the linking mechanics.

  • Treating "governance" as the security team's job. Governance authority comes from above the security team — from the board, from executive leadership, from the audit committee. A "governance program" run entirely by the security team without sign-off from leadership produces a program that can't make the decisions only leadership can make (accepting strategic risk, allocating budget, restructuring teams). Get the governance forum chartered at the right altitude; without that, the security team is doing two jobs and getting credit for neither.

  • Reviewing nothing. The whole governance module is built around review cadences — document next-review dates, exception expiration dates, project status updates. A program that never actually performs the reviews ends up with a register where every document was last reviewed in 2023 and every exception expired six months ago. Use the dashboards to surface what's overdue; act on them. The review cadence is what keeps the program honest.

Related