In many organizations, risk and compliance are treated as a brake applied after the car is built. In a robust target operating model, they are part of the vehicle’s design: the way you steer, how the braking system is built, and what safety features are standard.
This chapter focuses on how to integrate risk, controls, and compliance into your TOM rather than layering them on top:
- Defining risk appetite and ownership in concrete, operational terms
- Designing controls into processes and systems
- Setting up the “three lines of defense” in a way that actually works
- Structuring regulatory interfaces and assurance so they support the business
11.1 Defining Risk Appetite and Risk Ownership in the TOM
Risk appetite is often treated as a board-level document with little operational impact. For a TOM, you need something more practical: a clear statement of how much risk you are prepared to take, where, and under what conditions, combined with who actually owns which risks.
Think in three layers:
- Enterprise risk appetite
- Risk appetite by business / value stream
- Concrete limits, thresholds, and KRIs embedded in operations
Enterprise risk appetite
At the top level, risk appetite answers:
- How much volatility in earnings and capital are we willing to accept?
- How much operational, conduct, reputational, cyber, and compliance risk are we prepared to run?
- Where are we prepared to stretch, and where are we zero-tolerance?
This is typically expressed as:
- High-level statements (e.g., “We have no appetite for deliberate misconduct or regulatory breaches,” “We accept moderate operational risk if it is well-controlled and monitored”).
- Supporting metrics and ranges (e.g., maximum loss thresholds, capital buffers, tolerance for incidents).
For TOM purposes, your role as an executive team is to translate these statements into operating implications:
- “No appetite for X” means some activities are simply out of scope.
- “Low appetite” areas require tighter controls, more automation, stronger oversight.
- “Moderate appetite” areas may justify more experimentation and decentralization, but still with clear boundaries.
Risk appetite by business and value stream
The next step is to cascade appetite into the key value streams and business areas. Risk is not uniform:
- Retail vs. corporate vs. institutional businesses face different risk types and magnitudes.
- Digital-only journeys have different risks from manual or hybrid ones.
- Certain products or processes are inherently higher risk (e.g., complex deals, high-value payments, critical infrastructure).
For each major business / value stream, you should be able to answer:
- What are the top 3–5 risk types we are most exposed to here (e.g., credit, market, operational, conduct, technology, model, data, cyber, fraud)?
- What is our appetite level for each (low / moderate / higher) in this context?
- What are the operational signals that we are approaching or breaching that appetite (KRIs, near-miss patterns, outliers)?
This does not need to be perfect science, but it must be explicit enough to guide TOM design choices, such as:
- Level of automation vs. manual review.
- Thresholds for escalations and additional checks.
- Where to place more experienced staff and oversight.
Risk ownership
Appetite without ownership is meaningless. In a TOM, risk ownership should mirror your value stream and org design:
- First line (business / operations owners)
- Own the risks in their activities day-to-day.
- Are accountable for identifying, assessing, and managing those risks within appetite.
- Must be able to articulate their key risks and how they control them.
- Second line (risk and compliance functions)
- Own the frameworks, policies, and oversight for each risk type.
- Challenge the first line, monitor adherence to appetite, escalate concerns.
- Third line (internal audit)
- Provides independent assurance that the first and second line are effective.
In practice, you should create a simple risk ownership map:
- Rows: main risk types (credit, market, liquidity, operational, cyber, conduct, legal, regulatory, etc.).
- Columns: key businesses / value streams and key support functions.
- For each cell: clarity on who is accountable, who is consulted, and who is informed.
A quick test:
- Can each BU or value stream head state their top risks and how they are managed, without pointing immediately to the risk function?
- Can each risk-type owner (e.g., CRO, CISO, Head of Compliance) show how appetite is implemented in real processes and limits, not just in policies?
If not, your TOM still treats risk as a side function, not as part of the operating model.
11.2 Designing Controls into Processes and Systems (Not On Top)
Controls are how you translate risk appetite and ownership into everyday behavior. The worst way to implement them is to bolt them on after the fact: extra checklists, manual approvals, ad hoc sign-offs. The best way is to design controls into processes and systems from the start.
Think about controls along three dimensions:
- Purpose: preventive, detective, corrective
- Form: automated vs. manual; in-system vs. outside-system
- Placement: where in the process do they sit; who executes and who reviews
Preventive vs. detective vs. corrective
For each key risk in a value stream, you should ask:
- What could go wrong here (failure modes)?
- How can we prevent that from happening?
- If it still happens, how will we detect it quickly?
- How will we correct it and learn from it?
Example: new customer onboarding
- Preventive: identity checks, sanctions screening, credit policy rules, system-enforced mandatory fields and logic.
- Detective: sample-based review of cases, monitoring of unusual patterns, reconciliation of key data.
- Corrective: incident management, root-cause analysis, rule updates, training, system fixes.
Your TOM should emphasize preventive, automated controls wherever feasible. Detective and corrective controls are still needed, but if everything relies on them, you are building a fragile system.
Automated vs. manual; in-system vs. outside-system
You want as many critical controls as possible to be:
- Automated (or at least system-assisted).
- Embedded in the systems where work is done, not in parallel spreadsheets or email threads.
- Evidenced and auditable (the system logs what happened and why).
Typical embedded control patterns:
- Role-based access: users can only see and do what their role allows.
- Segregation of duties enforced by the system (e.g., one user cannot both create and approve a high-risk transaction).
- Validation rules: data format checks, range checks, cross-field consistency.
- Engine-based decisioning: rule engines and models that apply consistent policies.
- Exception workflows: anything that falls outside policy automatically goes into a structured workflow for review, with reason codes.
Manual controls (checklists, sign-offs, reviews) still have a place:
- Where judgment is needed and cannot be fully systematized.
- Where volumes are low or patterns are highly variable.
- As temporary measures while systems catch up.
But in TOM design, manual controls should be:
- Clearly defined (who does what, with what standard, at what frequency).
- Documented and traceable (e.g., in a workflow tool, not just email).
- Seen as targets for future automation where possible.
Ask in design reviews:
- “For this risk, what would it take for the control to be automated and system-embedded?”
- “If a control is manual, is it truly the best we can do, or a legacy convenience?”
Controls catalog integrated with processes
As you design value streams (Chapter 5), link them to a controls catalog:
- For each process step, list the key risks and associated controls.
- Mark each control as preventive/detective/corrective; automated/manual; in-system/outside-system.
- Prioritize controls that must be designed into new systems or workflows.
This is not just for audit; it becomes a design spec for technology and process teams. When systems change, they know which controls must be preserved, strengthened, or retired.
11.3 First, Second, Third Line of Defense: Practical Setup
The “three lines of defense” model is widely adopted, but often poorly implemented. In many firms it degenerates into:
- Overlap: multiple functions checking the same thing.
- Gaps: critical risks with no effective oversight.
- Friction: second line seen as “police” rather than partners.
Your TOM should define a clear, practical 3LoD setup that fits your size and regulatory environment.
First line of defense (business and operations)
Role:
- Own and manage risks in day-to-day operations.
- Run the processes, use the systems, and operate the controls.
- Perform regular risk and control self-assessments (RCSA) and respond to issues.
In the TOM, this means:
- Value stream owners and business heads are explicitly accountable for key risk metrics and control performance.
- Front-line managers trained to recognize and escalate risk issues, not just to hit volume or cost targets.
- First-line teams actively involved in designing and improving controls, not passive recipients.
Second line of defense (risk and compliance)
Role:
- Define frameworks, policies, and methodologies for managing each risk type.
- Provide independent oversight and challenge to the first line.
- Monitor adherence to risk appetite; aggregate and report risk across the enterprise.
In TOM terms:
- Second line functions must have clear organizational placement, typically reporting to the CEO or board committees (not to the business lines they oversee).
- They must be resourced and skilled to:
- Set and maintain policies and limits.
- Review and challenge first line risk assessments and proposals.
- Run thematic reviews and deep dives where needed.
- They should be embedded in key governance forums:
- Risk committees at enterprise and BU level.
- Product approval committees.
- Strategic investment and change councils.
Third line of defense (internal audit)
Role:
- Provide independent assurance to the board and executives that the first and second lines are effective.
- Evaluate design and operating effectiveness of governance, risk management, and controls.
- Recommend improvements and track remediation.
In the TOM:
- Internal audit keeps a clear line to the board or audit committee.
- Its audit plan is explicitly linked to:
- The TOM changes underway (new systems, reorganizations, shared services, outsourcing).
- The company’s risk profile and incidents.
Clarifying who does what
When designing the TOM, take a few critical activities and assign responsibilities line by line. For example:
- Risk policy setting
- 1st line: Input on feasibility and business impact.
- 2nd line: Drafts, owns, and maintains policies.
- 3rd line: Checks that policies are followed and effective.
- Product / journey approval
- 1st line: Business case, design, and primary accountability for performance and risks.
- 2nd line: Challenge on risk, compliance, and control design; sign-off thresholds.
- 3rd line: Later review of implementation and operation.
- Incident and breach management
- 1st line: Detects, logs, investigates, and implements fixes.
- 2nd line: Oversees severity classification, ensures appropriate escalation and reporting.
- 3rd line: Periodically reviews incident handling and themes.
Capture this assignment in simple RACI-like tables for core risk activities. Socialize them widely.
Good 3LoD implementation feels like:
- The business knows it owns risk, and sees risk and compliance as thought partners.
- Risk and compliance challenge constructively and consistently, not randomly.
- Internal audit provides a credible external check that the system works as designed.
11.4 Regulatory Interfaces and Assurance Mechanisms
For many industries, how you interact with regulators is itself a critical operating model component. A clear TOM helps you:
- Avoid fragmented, inconsistent messaging
- Reduce the burden and disruption of exams and inquiries
- Build trust that can be invaluable in difficult times
Regulatory interface model
Start by making the “who speaks to regulators” question explicit.
Key elements:
- Single enterprise regulatory coordination function or role
- Central point for managing regulatory relationships and calendars.
- Tracks incoming requests, deadlines, and commitments.
- Coordinates responses across functions and BUs.
- Accountable executive for each major regulator
- Typically a C-level or BU head.
- Responsible for the overall relationship and tone.
- Ensures consistent messaging across meetings and submissions.
- Local regulatory leads (in specific countries or business lines)
- Manage day-to-day interactions under the enterprise framework.
- Ensure local nuances are respected.
Your TOM should define:
- How regulatory correspondence is logged and tracked.
- How responses are drafted, reviewed (legal, compliance, relevant business), and approved.
- How commitments given to regulators are recorded and followed through.
Regulatory change and impact on TOM
Regulation is not static. You need a mechanism to:
- Scan for regulatory changes and guidance (horizon scanning).
- Assess impact on products, processes, systems, and data.
- Decide on TOM changes and prioritize them.
Practically:
- Create a regulatory change process owned by Compliance / Legal, with strong links to TOM governance and portfolio management.
- For significant changes, treat regulatory responses as TOM change projects, not patches:
- Clear design requirements.
- Alignment with existing processes and platforms (avoid one-off tactical fixes where possible).
- Controlled implementation and testing.
This prevents a proliferation of “regulatory bolt-ons” that slowly destroy the coherence of your operating model.
Assurance mechanisms beyond the three lines
In addition to 3LoD, your TOM should describe other assurance layers:
- Compliance monitoring and testing
- Periodic checks by second line to ensure specific rules and procedures are followed.
- Thematic reviews of high-risk areas or new TOM components.
- Quality assurance / quality control
- First line or shared services teams checking execution quality, independent of normal production.
- Particularly useful in high-volume or judgment-heavy processes.
- External audit and certifications
- Financial audits, SOC reports, ISO certifications, industry-specific audits.
- Provide external validation of controls for regulators and clients.
- Whistleblowing and speak-up mechanisms
- Channels for employees and stakeholders to report concerns safely.
- Integrated into investigation and remediation processes.
The TOM should specify:
- Where these assurance activities sit organizationally.
- How findings are reported and escalated (to Risk Committee, Audit Committee, Board).
- How assurance findings feed back into TOM evolution (e.g., process redesign, system changes, policy updates).
Documentation and evidence as part of the TOM
Finally, regulators and auditors rely heavily on documentation and evidence. Your operating model should make it easy to show:
- What your policies are and who owns them.
- How your processes and controls are designed and kept up to date.
- What actually happened: logs, approvals, exceptions, incidents, remediation.
That implies:
- Maintaining a single source of truth for policies, standards, and procedures.
- Ensuring systems produce sufficient, reliable audit trails.
- Standard templates for documenting processes, controls, and risk assessments.
If every exam requires a scramble to “reverse-engineer” your own operating model from people’s heads and hidden spreadsheets, your TOM is not truly documented.
