GRCOps

WHAT IT IS. GRC operations is the machinery by which an organisation decides what risk it will accept, writes that decision down, and revisits it when the world changes. Where compliance operations proves controls are working, GRC decides which controls should exist, who may waive them, and what the organisation does about the risks it has chosen not to fix. WHY IT EXISTS. Without it, risk lives in three incompatible places: a spreadsheet nobody has opened since the last audit, the heads of two senior engineers, and an incident channel. Policies are written once and never reconciled with how work actually happens, so people route around them and the gap between the documented organisation and the real one widens until an incident exposes it. This area exists to keep those two organisations the same one. WHEN TO USE IT. When decisions about risk start outliving the people who made them — typically at the point of regulated customers, board reporting, or a second product line. Small teams need the lightweight version: a short risk list with owners and review dates beats an enterprise platform nobody maintains. The failure mode is adopting heavyweight process before there is anything to govern. WHO OWNS IT. A risk or governance owner maintains the register, the policy set and the exception workflow; accountable executives own individual risks and must be named, because "the company" cannot accept a risk. Engineering supplies reality — what is actually deployed, what actually failed. Internal audit, where it exists, checks the machinery rather than running it. WHAT GOOD LOOKS LIKE. Risks have a named owner, an agreed treatment, and a review date that is honoured. Policies carry versions, effective dates and an owner, and each one maps to the controls that implement it, so a policy change visibly propagates. Exceptions are time-boxed, approved at the right level, and reviewed on expiry rather than renewed by silence. Third-party risk is assessed proportionally — a payments processor and a screenshot tool do not get the same questionnaire. Risk discussion cites evidence from /complianceops rather than opinion, and the register visibly changes after incidents. HOW TO IMPLEMENT. Build the register from real events first: your last five incidents, your top three dependencies, your known single points of failure. Give each entry an owner, a treatment decision and a date. Write the exception process before you need it, including who may approve what and for how long. Reconcile policies against practice once — expect the gap to be uncomfortable — and retire anything you do not intend to enforce. Connect the register to operational reality by reviewing it after every significant incident; the postmortem in /incidentops should be able to change a risk entry. HOW TO ASSESS YOURSELF. Can you name the owner and review date of your top five risks without opening a document? How many exceptions are currently expired but still relied on? When did a policy last change because practice showed it was wrong? Score your governance posture at /assess, and use /roadmaps to sequence the gaps you find.