ServiceNow Integrated Risk Management: Roles, Responsibilities and RACI

Core Roles in Risk Management

Risk management requires clear decision rights. Start with these core roles: Chief Risk Officer or equivalent executive sponsor who sets policy and receives escalated risks; Risk Process Owner who maintains risk register and schedules reviews; Risk Assessors who identify and evaluate risks; Mitigation Owners who implement controls; and Auditors who verify controls are effective.

Your organization may combine these roles (a small team might have one person doing assessments and audits) or distribute them (large enterprises split each function). Define which roles exist in your context and who fills them. Document this explicitly so everyone knows who to contact for each type of decision.

Risk Management Lifecycle RACI

Escalation Paths

Define when risks escalate. A risk assessed as low-impact within normal tolerance does not escalate; it is tracked in the register. A risk assessed as exceeding tolerance escalates to the process owner for review and prioritization. If mitigation is not possible (the risk is outside the organization’s control), it escalates to the executive sponsor for acceptance or strategy change. Create an escalation checklist: at what point does a risk rise to each level?

Time-based escalation also matters. If a risk mitigation is overdue, it escalates from the mitigation owner to their manager. If it remains overdue after a set period, escalate further. This prevents mitigations from slipping indefinitely.

Decision Rights

Who decides whether a risk is acceptable? The process owner typically makes routine decisions. The executive sponsor makes decisions that affect business strategy. Document the thresholds: risks with impact below X are decided at the process owner level; risks above X go to the executive sponsor. This prevents arguments about which level should decide.

Who decides what mitigations are required? If the risk falls within a specific domain (security risk, compliance risk, operational risk), the domain expert typically decides in consultation with the risk owner. Security risks are often decided by your Chief Information Security Officer. Compliance risks by your General Counsel or Compliance Officer. Operational risks by process owners.

Accountability for Control Execution

Mitigation owner and control owner may be different people. The mitigation owner is accountable for designing and implementing the control. The control owner is accountable for executing it on an ongoing basis (running a daily report, conducting a monthly review). Make this distinction clear so one person does not assume the other will execute.

For example, a cyber risk mitigation is “implement endpoint security software.” The mitigation owner is the IT security team who selects and deploys the software. The control owner is the IT operations team who ensures it stays updated and patched. Both roles are essential; unclear accountability creates gaps.

Governance and Review Cadence

Establish a review cadence: risks are reviewed quarterly by default, but high-impact risks are reviewed monthly. The risk owner drives the review: has the risk changed? Are mitigations on track? Has the control owner tested the control? Document review dates in the risk register so nothing is missed.

Establish governance meetings: the risk process owner runs a monthly meeting with risk owners to review status. The executive sponsor reviews quarterly reports on top risks. This rhythm ensures risks get attention consistently without being a constant emergency.

Ownership Gaps and Clarity

The most common problem is unclarity about risk ownership. Someone says “it is a risk” but no one owns the problem of ensuring mitigations happen. To prevent this, every risk record must have a designated risk owner who is accountable for tracking the risk to resolution. This person may delegate mitigation execution but retains accountability for oversight.

Similarly, every mitigation must have a mitigation owner. Every control must have a control owner. If you cannot name an individual, the role is not assigned and work will not get done. Use this as a forcing function: if you cannot assign responsibility, reconsider whether the mitigation is actually being planned or just discussed.

A decision-rights table for the exception and waiver process

Exceptions are where role definitions often break down. An exception lets a unit operate outside a standard for a set period, and every exception involves at least three roles: the person asking for it, the person who can grant it and the person who checks that it ends. A matrix designed around standard risk activities does not show those hand-offs clearly. The table below uses a different shape, listing each decision and the party who decides, the party consulted first, the evidence that must be attached and the reviewer who checks the decision later.

Common conflicts in role assignments and how to read them

A conflict in a role matrix shows up as a decision that two people believe they own, or as a decision that nobody believes they own. Both are visible in the register if you look for them. Two people both marked accountable for the same mitigation often means the scope was never split, so one of them will defer to the other. A mitigation with a responsible person and no accountable person often means the sponsor delegated without saying so. Ownership questions of this kind are taken up on the risk management accountability page. Reading a matrix for these patterns takes less time than debating it in a meeting, and it turns the discussion from who should be involved into what each person is actually expected to decide.

• Two accountable parties for one decision: split the scope or name one of them as the decider.
• No accountable party for a responsible one: the delegation is implicit, so write it down.
• The same person assessing a risk and approving its acceptance: separate the two roles, or record a second approver.
• A control owner who is also the only tester: arrange an independent check at least for high-rated controls.

Walking through the matrix with the people in it

A matrix nobody has walked through is a document, not a control. Run a walkthrough with a small group of real owners, using a few recent records rather than hypothetical cases. Ask each person to describe, in their own words, what they did on the record and whether they expected to be the one who did it. Where the description and the matrix disagree, change the matrix or change the practice, and record which one changed.

1. Choose three or four records from the last cycle, covering a new risk, a mitigation, an exception and a closure.
2. Ask the people who touched each record to describe their steps before showing them the matrix.
3. Compare each description with the matrix row for that step.
4. Record each mismatch as either a matrix change or a practice change, with the owner of the change.
5. Reissue the matrix with a version and date, and ask each owner to confirm their rows in writing.

Keeping the matrix current as people move

Role matrices go stale as people change jobs faster than the register is updated. Access follows the same pattern, as covered in platform access review. Tie matrix maintenance to the events that cause the drift. When a person leaves a role, the matrix row is reassigned before their last day. When a unit is restructured, every risk record owned by that unit is reviewed for the new owner. When a new control is added, its owner and tester are named before the control goes live. These are small steps, but they are the steps that often get skipped when the team is busy.

Questions about roles that teams raise once the matrix is in use

Can a risk owner delegate the work and keep the accountability?

Yes, and that is common. The delegate does the work, while the owner remains accountable for the outcome and for the decisions the delegate cannot take alone. Record the delegation on the record so that anyone reading it can see who did what.

Should the risk manager also be the risk owner?

Preferably not for significant risks. A manager who both coordinates the assessment and owns the response has an incentive to score the risk in a way that is easy to manage. Separating the two roles keeps the assessment independent of the response.

What happens to a matrix when the organization restructures?

Re-run the walkthrough on a sample of records from the affected units. Restructures often move accountability without moving the work, which leaves a gap that only shows up when a decision is due.

Is a RACI enough on its own?

No. A RACI says who does what, but it does not say what evidence a decision needs or how the decision is later checked. The exception table above shows why those two columns matter, particularly where a decision can be reopened.