Authority Before Paperwork
Governance is not a policy library. It is the answer to three questions: who is allowed to decide, on what basis, and who carries it when the decision is wrong. Committees, policies and RACI charts are machinery for making those answers stick — useful only once the answers exist.
Before writing anything, find the decisions already being made without you: which tools were bought last quarter, which vendor was onboarded, which model went into production. A programme that starts with a policy document governs nothing. One that starts with real decisions has something to attach authority to.
- Accountability Before Committees
- Ownership Before Process
- No Policy Without Ownership
Governance / Oversight Radar
Oversight responsibility sits with SLT and ELT, not just the GRC function. That means keeping a close, continuous watch on the teams operating underneath — visibility they can act on quickly, with clear accountability — so GRC teams can navigate risk and compliance programmes without negligence in other teams quietly becoming their problem to inherit.
That accountability runs both ways. The rest of the business needs to support risk and compliance work in a timely, ongoing manner — not treat it as a once-a-year exercise tolerated between audits.
Continuous risk monitoring and remediation is where this gets tested in practice. Risk owners have to stay actively involved, because deciding whether a risk is worth the investment to mitigate is a business call — one AI cannot make for you.
The same applies to acceptance. Where a risk category carries cost, direct or indirect, the decision has to be measured against the organisation’s risk appetite statement and its threshold — inside it, the owner accepts and moves on; outside it, the decision escalates, and what happens if it doesn’t should be written down before the situation arises, not decided in the room.
Charter and owner
A one-page charter: scope, who owns it, what needs approval before it proceeds. A named person, not a committee. A decision log, however crude.
Policies you will enforce
Acceptable use, third-party and AI procurement, data handling, exceptions. Four enforced beats twelve ignored.
A forum and a record
A recurring meeting with the right attendees, decisions written down, and a first report to leadership on what was decided and what was excepted.
Decide and Define What AI Governance Is? What Systems Require Proper Governance?
Connecting AI systems changes the risk surface, and the change moves faster than most governance frameworks account for. Every new connection — a plugin, an MCP server wired into an LLM, an agent given a tool it can call on its own — is a new decision point about what that system can reach and act on, not just what it can say.
Each of those integrations needs an owner, not just a build ticket. Someone accountable for what the agent is permitted to do, what happens when it does something wrong, and who signs off before it goes into production — the same way a person, not a policy document, is accountable for any other decision in the business.
What data goes into the system matters as much as what comes out. Every model, agent and MCP integration needs its inputs tracked and monitored — what it can see, what it can query, what it can write to — because the governance question is not only whether the output is right, it is whether the system should have had access to that data in the first place.
Where to Start, and How Big to Build It
A risk programme is not one thing, and it does not begin with a method. It begins with intake — deciding what the programme will actually take in. Technology and non-technology risk, operational, third-party and vendor, AI and model risk, exposure introduced by agents and MCP integrations, financial, regulatory. What you choose to receive determines the shape of everything downstream: who owns it, how it is scored, and what leadership ever hears about.
The simulation tool below works through nine questions covering scale, sector, driver, maturity, method, budget, timeline and team, plus one tailored to your industry. It returns two scenarios: two defensible ways the programme could be shaped, each with a method, framework and tooling position. Treat them as an illustration of what can reasonably be considered, not a prescription.
Risk Program Enablement Discovery Tool — directional guidance, not a substitute for judgement about your own organisation.
Continuous Compliance
Compliance is not a tick-box exercise. It is the practice of continuity — control assurance, audits, evidence collection and validation running throughout the calendar year, not compressed into the weeks before an audit.
Continuous compliance means ensuring a control is designed and operating effectively on a periodic basis. Designing and operating controls properly should be treated as security best practice in its own right — it is what keeps you ahead of future cyber attacks and data breaches, not just what satisfies an auditor.
Evidence collection and validation on their own are not enough. This requires the ground reality of control effectiveness: testing with the control owner to confirm they are actually following it and monitoring it. The passing criteria becomes the evidence — proof that the process was performed and executed the way it is supposed to be, not just a screenshot that it exists.
Staying on top of this is genuinely difficult in a fast-moving organisation, where change is the constant, moving target.
- Test controls with the owner, not just the artefact — walk the actual process, don’t just collect the screenshot.
- Set a rolling testing cadence through the year, not a rush before the audit window opens.
- Define the passing criteria before you test — that is what “operating effectively” means, and it is what becomes the evidence.
- Retest whenever the underlying process changes, not only on the fixed schedule.
- Track control ownership continuously — a control with no current owner isn’t being tested by anyone.
- Route every failed test into remediation with an owner and a deadline, not just a note in the register.
- Ground the approach in what regulators and auditors actually test for — SOC 2 Type II’s operating-effectiveness window, ISO 27001 surveillance audits, PCI DSS’s quarterly scan cadence, DORA’s resilience testing — not a generic notion of “staying compliant.”
Handing Continuous Compliance to AI
- Identify the gap across standards — SOC 1, SOC 2, ISO 27001, PCI DSS, ISO 42001, DORA, HIPAA, NIS2 — and put what’s missing into the roadmap for consideration.
- AI can generate a confidence score for how one standard maps to another. Useful enough to rely on, but not something to trust unconditionally every time.
- From ticket creation to notifying control owners — AI can run this end-to-end without human oversight.
- API-based evidence collection can satisfy some control-test criteria, not all of them.
- Data protection through to data retention: is customer data being used to train any AI models, what is the retention period, and what do the contractual obligations say. This is sensitive ground — data fed into systems that turn out not to be GDPR/CCPA compliant creates real exposure to significant penalties.
Obligations register
Every source of requirement in one place, with the clause that creates it. This is the artefact regulators ask for first.
One control set, cross-mapped
Write the control once, map it to every framework it satisfies. Maintaining four parallel control sets is how small teams drown.
Evidence by design
Decide where each control’s evidence comes from before the audit window opens. Anything you have to reconstruct will be reconstructed badly.
Subscribe here to get more updates on this space.