An operational governance framework is the documented system of decision rights, committees, policies and reporting lines that governs how an organisation runs its day-to-day operations, not just its projects. Get it right and decisions move faster because the right person can make the right call without three layers of escalation. Get it wrong and you get exactly what most organisations already have: meetings that decide nothing, risk registers nobody reads, and audit findings that repeat year after year.
The Basel Committee's operational risk guidance requires a board-approved risk appetite, a documented operational risk management framework, and clearly assigned roles. The OECD's governance principles frame this the same way for any organisation, not just banks: governance is an integrated system of policy, oversight and accountability aligned to strategy. Neither body treats governance as paperwork. Both treat it as the mechanism that makes resilience possible when things go wrong.
The primary outcomes a well-built framework delivers are:
- Aligned decisions — the person with the authority to decide is the person who actually decides, without a committee rubber-stamping something already settled.
- Better resource allocation — capital, headcount and management attention go where risk and opportunity actually sit, not where the loudest stakeholder shouts.
- Operational resilience — the organisation keeps critical services running under stress because roles, escalation paths and tolerances were agreed before the crisis, not during it.
Keystoneconsulting has spent many years helping healthcare, construction, government and facilities management teams turn these principles into working structures rather than binders on a shelf.
Key Takeaways
An operational governance framework only works when decision rights, committees, policies and reporting are documented, board-approved, and tested against real workflows rather than assumed org-chart behaviour.
| Point | Details |
|---|---|
| Definition and purpose | An operational governance framework sets decision rights, committees, policies and reporting to align decisions and build resilience. |
| Scope discipline | Keep operational governance distinct from project governance and the wider operating model to avoid design confusion. |
| Four core components | Accountabilities, committee charters, documented ORMF policies, and reporting tools form the non-negotiable base. |
| Model fits context | Centralised, federated, decentralised and matrix models each suit different scale and regulatory profiles. |
| Keystoneconsulting's approach | Keystoneconsulting maps real workflows first, then applies stage-gated governance and Videra's AI reporting for audit-ready outcomes. |
Table of Contents
- Operational governance vs project governance vs the operating model
- What are the core components of an operational governance framework?
- Which governance model fits your organisation?
- How do you design and implement an operational governance framework?
- Who is accountable under a three lines of defence model?
- What KPIs and KRIs make governance measurable?
- How does operational resilience fit into governance design?
- How does Keystoneconsulting apply this in practice?
- Primary sources and further reading
- Why practical resilience beats theoretical governance
- Get a governance framework built on how your teams actually work
- Frequently asked questions
- Sources
Operational governance vs project governance vs the operating model
Confusing these three terms is the single most common design mistake we see. An operational governance framework governs the running of the business: who approves what, which committees exist, how exceptions get reported, and which policies control day-to-day risk. Project governance is narrower and time-bound. It covers a specific initiative, its stage gates, its sponsor, and its business case. Once the project closes, that governance structure closes with it. The operating model is broader still. It is the entire system of how the organisation delivers value, covering structure, process, technology, people and governance together.
McKinsey's operating model research treats governance as one of roughly twelve interlocking elements in that wider system, alongside things like decision rights, incentives, and technology architecture. This matters because it explains why "operating model vs org design" is a false choice for most leaders: org design (who reports to whom) is a structural input to the operating model, while governance is the decision-making layer that sits across that structure. You can redesign the org chart and change nothing about how decisions actually get made.
Scope, in practical terms, means an operational governance framework should cover:
- Decision rights and escalation thresholds (who can approve what value, what risk, what exception).
- Policies and standards, including the documented operational risk management framework (ORMF).
- Committee structures and their terms of reference.
- Reporting cadence, content and audience.
- Controls and how their effectiveness gets tested.
What it should deliberately exclude is the mechanics of individual project delivery, and the wider questions of organisational design, incentive structures and technology strategy that belong to the operating model conversation. Keep governance artefacts (charters, policies, decision logs) in a single controlled repository rather than scattered across project folders. That single decision saves more audit pain than almost anything else on this list.
What are the core components of an operational governance framework?
Every functioning framework, regardless of sector, rests on four building blocks. Skip one and the whole structure gets shaky, usually in a way that only becomes obvious during an incident or an audit.
- Accountabilities and decision rights. Someone has to own each risk category, each control, and each type of decision. Write this down as a decision rights matrix, not a paragraph of prose that everyone interprets differently. Ambiguity here is where governance frameworks quietly fail.
- Committees and charters. The board sets risk appetite and approves policy. An executive committee translates that appetite into operating limits. Operational committees (change approval, incident review, product approval) handle the day-to-day decisions within those limits. Each committee needs a terms of reference that states its authority, its membership, its quorum, and how often it meets. A committee without a charter is just a recurring meeting.
- Policies and the documented ORMF. This includes a risk taxonomy so everyone uses the same language for the same risk, a control inventory that maps controls to the risks they mitigate, and defined approval routes for change and new products. The Basel Committee is explicit that this documentation isn't optional for regulated firms, and the discipline behind it holds up well even outside financial services.
- Reporting, data and tooling. Dashboards that show key risk indicators against tolerance, an audit trail that proves decisions were made by the right authority at the right time, and reporting that reaches the board in a form they can actually act on rather than a 40-page PDF nobody reads before the meeting.
Pro Tip: Build your decision rights matrix before you touch committee structures. Most governance redesigns start with the org chart and the meetings, then discover halfway through that nobody agreed who actually owns the decision in the first place.
The IFC's governance toolkits offer useful templates for organisations building these components from scratch, particularly the committee charter and policy documentation formats, which translate well outside the emerging-market corporate governance context they were originally designed for.
Which governance model fits your organisation?
There is no universally correct model, only the model that fits your scale, regulatory exposure and decision velocity needs. Four patterns cover most organisations.
- Centralised governance concentrates decision rights at group or head office level. It suits smaller organisations or those in tightly regulated environments where consistency matters more than speed, but it slows decisions as the organisation grows.
- Federated governance sets group-wide policy and risk appetite centrally while letting business units or regions make operational decisions within those bounds. Most mid-to-large organisations land here eventually because it balances consistency with local responsiveness.
- Decentralised governance pushes most decision rights to the business unit, with light central oversight. It works well for genuinely diversified conglomerates but creates real risk of inconsistent controls if central oversight is too thin.
- Matrix governance overlays functional oversight (risk, compliance, finance) across business or geographic lines. It offers the strongest control coverage but is also the slowest and most meeting-heavy model if not designed carefully.
Maturity is a separate question from model choice. Early-stage governance looks like ad hoc committees, undocumented decision rights, and reporting built the week before the board meeting. Mid-maturity organisations have documented policies and regular committee cadences but still struggle with data quality and timely escalation. Mature organisations run governance almost invisibly: dashboards update automatically, exceptions escalate on defined thresholds, and committees spend their time on judgement calls rather than status updates.
Oliver Wyman's analysis of malfunctioning governance identifies the classic warning signs: slow decision-making, siloed meetings that never actually decide anything, and management time consumed by governance theatre rather than governance substance. If that description stings a little, you already know where to start. The practical move to advance maturity without disrupting delivery is incremental: fix decision rights first, then reporting, then committee structure last, because restructuring committees before the underlying data and accountability exist just relocates the same dysfunction to a new room.
How do you design and implement an operational governance framework?
Building a framework from nothing, or fixing one that has drifted, follows a recognisable sequence. Skipping steps to move faster almost always costs more time later, usually in the form of a redesign eighteen months in.
- Run a 90-day diagnostic. Map every existing committee, decision right and policy against what actually happens in practice, not what the org chart claims happens. Interview the people who sit in the meetings, not just the people who chair them. This is also where you map stakeholders: who currently holds informal authority, who will resist change, and who needs to sponsor it at board level.
- Design the core artefacts. This means a decision rights matrix stating who approves what and at what threshold, terms of reference for every committee you intend to keep or create, and policies that state risk appetite and impact tolerances in concrete, testable terms rather than aspirational language.
- Pilot before you roll out. Choose one business unit, one region, or one risk category and run the new governance structure there first. Integrate the supporting tools at this stage too: dashboards for tracking key risk indicators, workflow maps that show where decisions actually flow, and reporting templates the pilot committee will actually use.
- Roll out with training and change governance. A new decision rights matrix means nothing if the people making decisions don't know it exists. Build training into the rollout, not as an afterthought. Set explicit board approval checkpoints for the framework itself, not just for the projects that sit underneath it, so the board owns the structure rather than merely receiving reports from it.
Pro Tip: Treat the pilot as a genuine test, not a formality. If a committee charter doesn't survive contact with a real escalation during the pilot, fix it before scaling. Rolling out a flawed structure across an entire organisation is far more expensive to unwind than delaying by six weeks.
One design choice worth flagging specifically: where operational governance meets project delivery, rigid stage gates can slow decisions to a crawl. Research into hybrid Agile-Stage-Gate models in manufacturing found that blending agile decision cycles with formal stage gates improved time to market and success rates for new products, without abandoning the control points that governance exists to provide. The lesson generalises: governance for agile delivery doesn't mean abandoning gates, it means making the gates lighter and more frequent rather than heavier and less frequent. An agile governance model built this way keeps the board's oversight intact while letting delivery teams move at a pace that doesn't require a committee sign-off for every increment.
Keystoneconsulting's approach mirrors this sequence directly, mapping existing workflows before recommending a single change, because a framework designed against a fictional version of how the organisation actually works is a framework that fails within a year. Organisations comparing platforms at this stage often find it useful to review enterprise project governance platform options alongside their own diagnostic findings.
Who is accountable under a three lines of defence model?
The three lines of defence model gives operational governance its accountability structure, and it only works when each line's responsibilities are written down rather than assumed. Most governance failures we see trace back to a gap between two lines, not a failure within one.
- The board sets and approves the risk appetite and tolerance statement, approves major policies, and holds senior management accountable for operating within agreed limits. Board oversight is not a rubber stamp exercise. The SEC's guidance on disclosure and oversight reinforces that boards carry direct responsibility for the adequacy of the governance structures they approve, not just the outcomes those structures produce.
- The first line (business and operational teams) owns the risks it creates and the controls that manage them day to day. First-line staff identify issues as they arise and are responsible for remediation, not just detection.
- The second line (risk and governance functions) sets policy, provides independent challenge to first-line decisions, and monitors whether the framework is actually being followed rather than just documented. This line owns the risk taxonomy and the control inventory.
- The third line (internal audit) provides independent assurance that the whole structure works as designed, tests controls directly, and escalates findings that the first and second lines missed or downplayed.
The handover points between lines need to be explicit in committee terms of reference: who reports what, to whom, and on what cadence. A framework that names all three lines but never states how information passes between them isn't really operating a three lines model at all.
What KPIs and KRIs make governance measurable?
Governance that can't be measured can't be improved, and boards increasingly expect quantified evidence rather than narrative assurance. A handful of metrics do most of the work.
- Decision lead time — how long it takes from issue identification to decision, broken down by committee or decision type.
- Control failure rate — the proportion of tested controls that fail, tracked over time rather than as a single snapshot.
- Exception backlog — the number and age of unresolved exceptions sitting above the agreed risk tolerance.
- Escalation timeliness — whether issues actually reach the right committee within the timeframe the policy specifies.
Thresholds should tie directly to the board-approved risk appetite and impact tolerance statements the Basel Committee's guidance calls for, not to arbitrary round numbers picked because they look tidy on a dashboard. An exception backlog of five items might be fine for one risk category and a serious breach for another, depending on the tolerance set for that category specifically.
Statistic Callout: The MAS consultation on updated operational risk guidelines reinforces that regulators expect a documented taxonomy, formal risk appetite statements, and clear committee charters as baseline evidence of an effective framework, not optional extras layered on top of a working structure.
Dashboards for executives should show trend and exception, not raw data. Committees need frequency matched to risk velocity: monthly for stable operational risks, weekly or event-driven for anything moving toward a tolerance breach. Every escalation should leave an audit trail that shows who was told, when, and what they decided.
How does operational resilience fit into governance design?
Operational resilience turns governance from a compliance exercise into a survival mechanism, and regulators now expect the two to be designed together rather than as separate workstreams. That starts with identifying which operations are genuinely critical, meaning the ones whose failure would cause material harm to customers or the wider system, and setting impact tolerances for each: the maximum tolerable disruption before harm becomes unacceptable.
From there, governance needs to absorb business continuity planning, third-party and supply chain risk, and ICT resilience into the same reporting and escalation lines as everything else, rather than running them as parallel, disconnected processes with their own committees and their own language.
- Map critical operations and agree impact tolerances at board level, not within a single risk function.
- Fold continuity, third-party and technology resilience into the standard reporting cadence rather than a separate annual exercise.
- Test resilience through realistic scenarios, following the direction set by both the Basel Committee and the MAS consultation paper, both of which push firms toward documented impact tolerances integrated into governance rather than standalone continuity plans.
- Close the loop after every incident: feed findings back into the risk taxonomy and control inventory, not just into a lessons-learned document that nobody revisits.
How does Keystoneconsulting apply this in practice?
Keystoneconsulting's method starts with mapping the workflows that actually exist, not the ones described in the policy manual, then builds stage-gated governance around what that mapping reveals. The gap between the two is usually where the real risk lives.
The Videra platform then turns that mapped structure into something usable day to day: AI-powered reporting that generates audit-ready exception reports and board packs directly from the workflow data, rather than someone manually assembling a slide deck the week before the meeting.
- Workflow mapping identifies where decisions actually happen versus where the org chart says they should happen.
- Stage-gated governance embeds approval points into the workflow itself rather than as a separate compliance checklist.
- AI reporting produces exception and board reports with a built-in audit trail, cutting the manual reporting burden that consumes so much second-line and secretariat time.
Pro Tip: If your governance reporting still takes days to assemble by hand, that's usually a sign the underlying workflow was never actually mapped. Reporting bottlenecks are a symptom, not the disease.
Readers working in construction delivery specifically may find the sector-specific detail in governance-first process improvement for construction directly applicable to their own pilot design.
Primary sources and further reading
- OECD — corporate governance
- Principles for the sound management of operational risk (BCBS)
- IFC corporate governance methodology and tools
- U.S. Securities and Exchange Commission (SEC)
- How to create an effective operating model (McKinsey)
- Videra PM configurable project delivery platform
Why practical resilience beats theoretical governance
Most governance advice treats the framework as an end in itself: get the policy right, get the committee structure right, and the organisation will follow. The evidence points the other way. Oliver Wyman's diagnosis of slow decisions and meeting-heavy committees describes a symptom of governance built as documentation rather than as a working decision system.
The conventional advice oversells structure and undersells sequencing. Fix decision rights before you touch committees. Fix reporting before you redesign the model. Most redesigns fail because they reorganise the furniture before checking whether anyone actually knows who is meant to sit where.
What the evidence on hybrid agile-stage-gate models suggests and what Keystoneconsulting's own delivery work confirms is that speed and control are not opposites. The organisations that get this right build governance that disappears into the workflow rather than sitting on top of it as a separate, resented layer. Start with the diagnostic, not the org chart.
Get a governance framework built on how your teams actually work
Most operational governance advice tells you what a framework should contain and leaves you to build it with spreadsheets, static policy documents and a reporting process that eats a week of second-line time every month. Keystoneconsulting takes a different route: it maps your actual workflows first, then builds the decision rights, committee structures and stage gates around what that mapping reveals, not around a generic template.
The Videra platform carries that structure forward day to day, turning mapped workflows into audit-ready exception reports and board packs generated automatically rather than assembled by hand. That matters most for teams in healthcare, construction, government and facilities management, where audit scrutiny is constant and reporting time is the scarcest resource on the team. If you're weighing this against a traditional consultancy engagement, the practical difference is that Keystoneconsulting stays embedded with your teams rather than handing over a report and leaving.
If your governance reviews still take days to prepare or your committees spend more time in status updates than decisions, explore Keystone Strategic Consultants' delivery governance services or look directly at Videra PM's configurable project delivery platform to see how the mapping and reporting work together, and get a pilot scoped for your team.
Frequently asked questions
What is the difference between an operational governance framework and an operating model?
An operational governance framework covers decision rights, committees, policies and reporting. The operating model is the broader system that also includes structure, process, technology and incentives, with governance as one component inside it.
Does operational governance apply outside regulated industries like banking?
Yes. The OECD's governance principles apply the same logic of policy, oversight and accountability to any organisation, and sectors like healthcare, construction and government face comparable pressure to document decision rights and control ownership even without a banking regulator involved.
How long does it take to design and implement a new governance framework?
A structured diagnostic typically runs around 90 days, followed by a pilot in one business unit or risk category before wider rollout. Full maturity, where reporting and escalation run largely without manual intervention, usually takes over a year to reach.
What is the biggest cause of governance framework failure?
Undocumented or ambiguous decision rights. Organisations frequently redesign committees and reporting before agreeing who actually owns each decision, which relocates the original confusion rather than resolving it.
How does governance for agile delivery differ from traditional stage-gate governance?
Governance for agile delivery keeps the same control points but makes them lighter and more frequent. Research into hybrid Agile-Stage-Gate models found this approach improved time to market without weakening the underlying controls that formal stage gates provide.
Sources
- Principles for the sound management of operational risk (BCBS)
- OECD — corporate governance
- IFC corporate governance methodology and tools
- U.S. Securities and Exchange Commission (SEC)