The CTEM Operating Model: Roles, Rhythm and Governance That Hold Up

• Why programmes stall without an operating model
• The six roles a CTEM programme needs
• How to size the team realistically
• The daily to quarterly operating rhythm
• Who decides what, and how disputes escalate
• How to produce audit evidence as a by product
• Signals that the model is failing

Tooling is rarely the reason CTEM stalls

When a CTEM programme stops delivering, the cause is usually structural rather than technical. Nobody owns the decision about what is in scope. Prioritization is re argued every cycle because no rule was written down. Validated findings sit unassigned because ownership was never agreed. The operating model is the artefact that removes those recurring arguments, and it costs nothing but the effort of writing it down and getting it agreed.

The six roles

These are accountabilities, not headcount. In a small organisation one person may hold three of them, and that is fine as long as everyone knows which hat is being worn. What breaks programmes is a role that belongs to nobody, especially the exception owner.

• Executive sponsor: owns scope, funds the programme, resolves ownership disputes and receives the quarterly report
• Programme lead: runs the loop, owns the calendar and the reporting line, and chairs the escalation
• Exposure analyst: discovery, prioritization and preparing decision ready work items
• Validation engineer: designs and executes safe tests and records the evidence
• Asset owners: accountable for changing the systems they run, and for accepting risk when they do not
• Risk and governance: owns the exception process, expiry enforcement and audit evidence

Size the team for the loop, not for the backlog

A common error is staffing to process every finding. That target is unreachable and demoralising. Staff instead to keep the loop turning at an agreed cadence for an agreed scope: enough analyst capacity to prepare a weekly prioritization review, enough validation capacity to test the top items each cycle, and enough programme capacity to chase owners. If capacity is short, reduce scope rather than skipping stages, because a shallow loop over a small scope produces more risk reduction than a broken loop over everything.

The operating rhythm

Cadence is what makes CTEM continuous rather than aspirational. Fix the meetings, keep them short, and make the inputs and outputs of each one explicit so they cannot drift into status reporting.

Decision rights prevent the same argument every cycle

Write down who decides each recurring question and what happens when there is disagreement. Three decisions cause almost all the friction: what is in scope, what gets fixed first, and who may accept risk. Assign each of them to a single role, define the escalation path, and set a time limit so a stalled decision automatically rises rather than quietly waiting.

1. 1Scope: proposed by the programme lead, approved by the executive sponsor, reviewed quarterly.
2. 2Priority: set by the exposure analyst using the published model, challenged at the weekly review, arbitrated by the programme lead.
3. 3Validation approval: requested by the validation engineer, approved by the asset owner within the agreed constraints.
4. 4Risk acceptance: requested by the asset owner, reviewed by risk and governance, approved at a level matched to the risk tier.
5. 5Escalation: any decision open for more than one cycle rises automatically to the sponsor.

Governance evidence should be a by product

If audit evidence is assembled manually before each audit, the programme is paying twice. Design the workflow so the evidence exists naturally: scope records signed off in the ticket system, validation evidence attached to work items, exceptions with owners and expiry dates in the same system, and metrics generated from that data. Then an audit becomes a query rather than a project.

Signals the model is failing

Watch for a small set of symptoms that reliably indicate structural problems: validated items with no owner after two cycles, the same priority argument recurring monthly, exception counts growing without review, validation deferred every cycle for capacity reasons, and quarterly reports that describe activity because outcomes cannot be calculated. Each one maps to a specific fix in the model rather than to more tooling.

• Assign the six accountabilities by name, even if one person holds several.
• Publish the cadence and protect the meetings in the calendar.
• Write down decision rights for scope, priority and risk acceptance.
• Set an automatic escalation for any decision open longer than one cycle.
• Design workflows so audit evidence is created by the work, not before an audit.

• Launching a CTEM programme with tooling but no defined ownership.
• Staffing to clear the backlog instead of to sustain the loop.
• Leaving the exception owner role unassigned.
• Letting cadence slip until the loop is effectively quarterly.
• Assembling audit evidence manually after the fact.