Risk Response in IRM Risk Management

Mary Hain · 3 hours ago

Risk Response in ServiceNow IRM is the structured process that kicks in once a risk assessment is complete and the residual risk exceeds your defined appetite. It's the "now what?" step where your team decides whether to mitigate, avoid, transfer, or accept a risk, and then executes that decision through a tracked, auditable workflow.

Each response type generates its own Risk Response Task, assigned to a task owner, and follows a defined set of states: Draft → Work in Progress → Awaiting Approval → Closed. When the task closes, the risk record automatically transitions to Monitor state with no manual intervention needed.

Watch the Risk Response Workflow video in the Risk Management Speed Learning Series on YouTube to learn more. A PPT for the hands-on training is also available as an attachment to this post.

How does it work?

Configuration starts in the Risk Assessment Methodology (RAM), where admins control when risk response is triggered: always, conditionally (e.g., when appetite status is Outside Tolerance), or via a custom script for complex business rules.

The GRC Approval Configurator handles multi-level approvals out of the box, with four default approval configs aligned to each response type. Within a task, Action Items act as the execution gate, granular assignee-level tasks that must all reach Closed state before the Risk Response Task can move to Awaiting Approval. Accept-type responses are the exception: they skip action items entirely and route directly to a dedicated acceptance approval workflow requiring leadership sign-off.

What is the value of Risk Response to my program?

The practical value here is straightforward. Risk Response closes the risk lifecycle so that it's documented, role-accountable, and audit-ready. Risk owners oversee the outcome. Assessors evaluate and hand off tasks. Admins configure the guardrails.

The workflow enforces structure. Team members can't skip steps, approve with open items, and can't quietly change strategy mid-task. For teams under regulatory scrutiny, that paper trail matters. For everyone else, it means risks aren't open forever.

FAQ — Risk Response in IRM Risk Management

When does a Risk Response Task get created? It depends on your RAM configuration. You can set it to trigger always (for every assessment), conditionally (e.g., only when residual risk breaches appetite or tolerance), or via a custom script for unique business requirements. Disabling risk response entirely is possible but not recommended.
What are the four risk response strategies?

Mitigate: Reduce the risk through controls or process changes
Avoid: Eliminate the activity causing the risk entirely
Transfer: Shift the financial or operational impact to a third party
Accept: Document a conscious decision to take no further action, typically when the risk is within appetite or the cost of response outweighs the potential loss

Can I assign multiple response strategies to a single risk? Yes. You can combine strategies: for example, Mitigate plus Transfer on the same risk. Each strategy generates its own separate Risk Response Task with its own workflow and approval chain.

What happens if I choose the wrong response strategy? You cannot convert a task from one strategy to another mid-workflow. Cancel the existing task and create a new one with the correct strategy.

What are Action Items and are they always required? Action Items are granular, assignee-level tasks created within a Risk Response Task to track execution steps. They follow their own 5-state workflow: Draft → Assigned → Work in Progress → Review → Closed. All action items must be closed before the Risk Response Task can move to Awaiting Approval. Note: Action Items are not available for Accept-type responses.

Who can approve and close a Risk Response Task? By default, the Risk Owner is the approver for all response types. Admins can configure additional approval levels — Level 2, Level 3, and beyond through the GRC Approval Configurator. Approval types include specific users, dynamic approvers, approval from source, or custom scripts. Only the Risk Owner can ultimately close the task.

What happens when a Risk Response Task is rejected? Whether it's an Action Item review or the full Risk Response Task approval, rejection sends the record straight back to Work in Progress for revision. The approver's comments are captured for traceability.

What's the difference between a Risk Response Task and an Issue? Risk Response Tasks are proactive, meaning a risk has been assessed and exceeds tolerance but hasn't yet materialized. Issues are reactive, meaning something (an audit finding, a control failure, a compliance breach) has already gone wrong. The quick test: Has the risk already materialized? If Yes → Issue. If No → Risk Response Task.

What role does the RAM play in risk response configuration? The Risk Assessment Methodology allows admins to enable risk responses, set trigger conditions, and link issues to assessments. It must be published before risk response workflows are active. Each risk response behavior (i.e., mandatory, conditional, or disabled) is controlled within the RAM configuration.

Where can I learn more? Visit ServiceNow product documentation on managing risk response workflows, or join the discussion on the ServiceNow GRC Community.

Some useful resources