Decide, weigh the risk, prove it: GRC as one loop.

OCEG, an industry body that publishes a GRC Capability Model, frames the discipline around reaching objectives while handling uncertainty and acting with integrity. The three columns above are one practical reading of that idea.

1. Leadership sets objectives and states how much risk it will carry to reach them.
2. The risk team asks what could block each objective and ranks the answers against that appetite.
3. Chosen treatments become controls, each with an owner and a test.
4. Compliance maps those controls to every outside obligation and collects proof as they run.
5. Failed tests, incidents and audit findings return to leadership, which may change the objective, the appetite or the budget.

The Govern function in NIST CSF 2.0 writes this circle into a security framework. Its categories cover strategy, roles, policy and oversight, and they expect the results of risk work to change what leaders decide next.

• Policies signed by someone who left. Governance survives on paper while nobody owns the decision any more.
• A risk register opened once a year. Risk work exists to satisfy an auditor rather than to shape choices.
• One spreadsheet per framework. The same access review is described three ways and evidenced three times.
• Audit-week panic. Evidence is gathered after the fact, so gaps appear when they are hardest to close.
• Board packs full of control counts. Directors see activity, not exposure, and cannot tell whether risk rose or fell.

Map at the level of each requirement, then keep one evidence record per control run. An auditor for any framework can sample that same record.

Vendors sell GRC platforms that store policies, risks, controls and evidence, and that connect to cloud accounts to pull proof automatically. They save real effort once owners, scales and mappings are settled. Bought first, they tend to digitise confusion: empty registers, imported policy templates nobody has read, and alerts nobody triages.

• Settle owners and risk scales before you pick a tool.
• Confirm the tool can hold one control against several frameworks.
• Keep exports in a format you can take elsewhere.
• For many small teams, a well-kept shared spreadsheet is enough to start.

• List your obligations. Every law, regulator direction, contract clause and standard you must meet, each with an owner.
• Agree one risk scale. Define low, medium and high in money, downtime or customer harm.
• Build one control library. Describe each control once, then map it to every obligation it serves.
• Capture evidence as you go. Tickets, logs and sign-offs saved at the time, not rebuilt before an audit.
• Report exposure, not activity. Give leadership the top risks, their direction of travel and the decisions needed.

Sources: OCEG GRC Capability Model (public overview); NIST Cybersecurity Framework 2.0, Govern function; ISO/IEC 27001:2022 Annex A control titles; AICPA 2017 Trust Services Criteria; ISO 31000:2018 public summary.