ServiceNow Governance, Risk and Compliance: Roles, Responsibilities and RACI

Understanding GRC Accountability

Governance, Risk and Compliance requires clear accountability across multiple functions. The Chief Risk Officer owns enterprise risk strategy and ensures risk management is embedded in business decisions. Compliance officers ensure the organization meets regulatory requirements and maintain audit evidence. Business unit leaders own the controls operating in their functions. Policy owners maintain policies and track compliance. Risk committee members (executives) review significant risks and approve mitigation strategies. Without clear delineation, accountability gets diffused and nothing gets managed effectively.

Core Roles in GRC

Chief Risk Officer (CRO): Owns the overall risk management framework, sets risk appetite, approves risk mitigation strategies for enterprise-level risks, and reports to the board or audit committee. Compliance Officer: Ensures compliance with applicable regulations, standards, and internal policies. Maintains audit evidence and manages regulatory relationships. Updates organizational compliance assessments when regulations change. Internal Audit: Independent verification that controls are operating effectively. Reports findings to leadership and audit committee. No audit work should be approved by the person being audited. Compliance Coordinator: Implements compliance programs, tracks policy acknowledgments, manages audit schedules. Reports to Compliance Officer. Risk Manager: Facilitates risk identification and assessment across business units, maintains risk register, coordinates mitigation efforts. Reports to CRO. Business Unit Leader: Owns risks and controls operating in their function. Ensures staff understand risk policies. Escalates significant risks. Control Owner: Executes the specific control (for example, code review process, data backup verification). Provides evidence that the control is operating.

RACI Matrix for GRC Lifecycle

Escalation Paths for Risk Events

Establish clear escalation thresholds based on risk severity and business impact. Control failures (evidence that a control did not operate) should be escalated from Control Owner to Business Unit Leader to Risk Manager. Escalate if the failure affects multiple instances or cycles, or if it indicates a systemic problem. High-risk findings from audits should escalate from Internal Audit to CRO to the Audit Committee (board oversight). Compliance violations should escalate from Compliance Officer to CRO to leadership depending on severity and regulatory impact. Define timelines for escalation (for example, escalate within 24 hours of discovery for high-risk events) to prevent issues from lingering without visibility.

Handling Ownership Gaps and Conflicts

When a risk or control spans multiple business units, designate a primary owner (typically the unit with the highest impact from the risk) and secondary owners from other affected units. Document shared accountability so expectations are clear. For conflicts (for example, Compliance Officer and Business Unit Leader disagree on control adequacy), escalate to CRO for resolution. When audit identifies a control that should be owned but isn’t, designate an owner during the audit response process and document the change.

Independence and Audit Separation

Internal Audit must be independent from the functions being audited. Audit reports should go to the Audit Committee, not to business unit leaders. Auditors should not audit work in areas where they have operational responsibility. Compliance Officer should not approve their own compliance assessments; this should be reviewed by Internal Audit or an independent party. Independence ensures credibility of audit and compliance assurance.

Annual Governance Cycle

Structure the GRC governance calendar around key events: risk assessment (annual or semi-annual), policy review (annual), audit schedule (annual), compliance reporting to regulators (per regulatory calendar), and board oversight (quarterly or at-need). Assign accountability for each event: who owns the schedule, who participates, who approves outcomes. Publish the calendar so all stakeholders know when escalations and decisions should occur.

Working through a control miss as a sequence of decisions

Consider a hypothetical team that finds its quarterly access review for a finance application was not completed on time. This is an illustrative case, not a record of a real event. The control owner is a business manager, the evidence is held by a compliance coordinator, and the finding would fall to internal audit. Nobody has acted in bad faith, yet three people each believe another is chasing the review. The case shows why an accountability matrix has to be read as a sequence of decisions rather than a grid of names. The first call is whether the miss is a control failure or a scheduling slip, and that call belongs to the risk manager. The control owner has a stake in the answer, so the owner should not make it.

Decision rights when a role is vacant

Ownership often breaks when a person leaves, not when the design was wrong. The table sets out what an interim holder may decide and what has to wait for the permanent appointment.

A sequence for resolving an unclear owner

1. Confirm the control or risk record in dispute and the period it covers.
2. Check the approved matrix for the accountable role, not for the person who currently fills it.
3. If the matrix names two accountable roles or none, record the gap and send it to the forum that approved the matrix.
4. Assign a temporary accountable owner in writing, with the expiry tied to the next committee meeting.
5. Correct the matrix at that meeting, so the temporary arrangement does not quietly become permanent.

Testing whether the matrix holds under pressure

A grid that reads cleanly on paper can still break when a decision is urgent. Test it by picking three recent decisions and tracing each back to the role that made it. If a decision was made by someone the matrix does not authorize, either the matrix or the practice needs to change. Check that each accountable role has a named person and a backup, and that the backup has seen at least one decision they would be expected to take. Task routing inside the platform is a separate question, and for keeping routing aligned with the matrix, see the assignment groups governance guide. Ask each backup to name the first decision they would take and whether they would need the owner’s sign-off to take it. A matrix nobody has rehearsed is a diagram, not a control.

Keeping the matrix aligned with the operating model

When the platform’s operating model changes, the matrix must change with it. A new shared service that takes over evidence collection, or a business unit that is merged into another, moves accountability whether or not the grid is redrawn. Make the matrix an output of the operating model review rather than a separate document that is updated when someone remembers. The platform operating model governance page describes OBLYTECH’s work on those structural changes.

Questions teams ask about role ownership

Can the same person be the control owner and the tester of that control?

Not where the test is meant to give independent assurance. The owner can record a self-assessment, but testing should sit with someone who does not run the control, or with internal audit for higher-risk controls. For common ownership errors, see the common mistakes page.

Should the risk manager be separate from the chief risk officer’s delegate?

In a smaller organization the same person often covers both, but the matrix should keep the roles apart. One role records and maintains the register, and the other approves decisions made against it.

A business leader refuses to accept a risk assigned to them. What happens?

The matrix should send the disagreement to the escalation forum rather than leaving the risk without an owner. Record the refusal, the reasons and the forum’s decision, so the position is visible to the next audit.

How often should the matrix be reviewed?

At minimum whenever a named role changes, and as part of the annual governance cycle. A matrix not amended since the last reorganization may be describing a structure that no longer exists.

Where to take the next step

A matrix the business does not recognize is often repaired by walking real decisions through it, not by redrawing the grid.