ServiceNow Integrated Risk Management Requirements Workshop Questions

Workshop Format and Preparation

A requirements workshop brings together stakeholders to define Integrated Risk Management strategy and configuration. Workshop length depends on scope and on how many stakeholders take part. Participants should include: risk owners (compliance, security, audit), process owners (operations), IT architecture, finance or business leadership. Before the workshop, send participants a brief explaining the purpose, scope, and expected outcomes.

The questions below guide discussions. You will not ask all questions in a single workshop. Instead, select questions relevant to your organization’s risk profile and business model. Use questions to prompt discussion and document answers that will drive design decisions.

Risk Identification and Assessment

What are your organization’s top 10 risks by business impact? Risk assessment starts here: identify risks that would materially affect business if they occurred. Ask: what risks keep leadership awake at night?

How do you currently identify risks? Are risks identified through formal risk assessment, incident response, compliance requirements, or leadership discussions? Your process may be informal or formal. Document the current process to understand what to preserve or improve.

Who is accountable for each risk? Risk ownership is critical. If no one owns a risk, it does not get managed. Design considerations: does Integrated Risk Management define and track risk ownership clearly? Can you assign risks to individuals or teams?

What time frame do you use for risk assessment (current state, 1-year forward, 3-year forward)? Different time frames apply to different risks. Current risks need immediate mitigation. Future risks need monitoring and planning.

Risk Governance and Controls

How are risks related to controls? What controls exist to mitigate your top risks? Design consideration: does Integrated Risk Management need to track control-risk relationships to show risk coverage?

Who monitors control effectiveness? How is control performance measured and reported? Many organizations have controls that exist on paper but are not actually executed or monitored. Integrated Risk Management should support control monitoring and provide evidence of execution.

What does control failure look like? Define failure criteria for each control so you can detect when controls break. This drives the metrics you need to track and alerts you need to set up.

How do you handle control gaps or deficiencies? If a risk exists but no control addresses it, what is your process to close the gap? Integrated Risk Management should track gaps and remediation plans.

Compliance and Regulatory Requirements

What compliance frameworks apply to your organization (internal policies, industry standards like ISO 27001, regulatory requirements like GDPR)? Integrated Risk Management typically maps risks to compliance requirements so you can show compliance to regulators.

How do regulators or auditors currently assess your risk management? Do they send questionnaires, conduct site visits, request evidence? Understanding audit processes helps you design Integrated Risk Management to generate the evidence regulators need.

What evidence must you maintain for audit purposes? Different frameworks require different evidence (control test results, risk assessments, board approvals). Your system must capture and organize this evidence automatically.

How often must you reassess risks (quarterly, annually)? Compliance requirements may drive risk assessment frequency. Integrated Risk Management must support your required assessment schedule.

Business Impact Analysis and Resilience

What are your critical business functions that must not fail? Business continuity starts with understanding what is critical. Ask leadership: if this function failed, what would happen to the business (revenue loss, customer impact, regulatory violation)?

For each critical function, what is the acceptable downtime? Recovery time objective defines how quickly function must be restored. Design consideration: does Integrated Risk Management track recovery time objectives and monitor actual recovery performance?

What is the financial impact of downtime for each critical function? Cost of downtime drives investment in resilience and recovery capabilities. Integrated Risk Management should help you understand where to invest.

How do you currently handle disasters or major incidents? What is your playbook? Design consideration: should Integrated Risk Management integrate with incident management to track recovery progress?

Metrics, Reporting and Escalation

Who needs to see risk metrics? Risk dashboards are typically for the board, C-suite, department heads, and risk committees. Different audiences need different metrics. Design consideration: which views and reports does Integrated Risk Management need to provide?

What metrics matter most to leadership? Risk trend (getting better or worse), risk concentration (are all risks in one area), and risk response status (how many risks have mitigation plans). Design your dashboards based on what leadership actually cares about.

When should risks escalate automatically? Define escalation rules: a risk becomes critical when likelihood increases, or when a control fails, or when a new incident shows the risk is active. Escalation ensures leadership sees critical risks promptly.

How frequently should risk reports be generated and reviewed? Board-level reports might be quarterly, operational reports weekly or monthly. Design review schedules and report frequency accordingly.

Design Impact Summary

Your answers drive design decisions: risk assessment frequency and process design, risk ownership model and escalation authority, control tracking requirements and evidence capture, reporting and dashboard design, integration with incident and compliance management, and roles and permissions for risk management activities.

Warning Signs From Common Implementations

If workshop participants cannot clearly identify top risks or who owns them, risk governance is unclear. You may need to do additional discovery before configuration.

If participants describe risk management as primarily audit-driven, the focus may be on evidence collection rather than actually reducing risk. Balance is needed: evidence matters for audit, but the goal is reducing risk exposure.

If there is significant disagreement on how risks should be managed or what risks matter most, you have a governance problem. Integrated Risk Management alone cannot resolve that. Address governance before or during implementation.

Preparing a data pack so the workshop answers real questions

Workshops that rely on participants to remember how the current process works tend to produce vague answers. A short pack sent beforehand changes the quality of the discussion. Include one page on the current register and how many records it holds, a list of the source systems the team believes hold risk data, the most recent committee minutes that mention a risk decision, and the audit findings from the last cycle that concerned risk. The audit management questions are a separate set worth preparing alongside it. Participants who read the pack arrive ready to correct it rather than to describe it from scratch, and the facilitator spends the session on design choices rather than on archaeology.

Turning answers into a decision record during the session

Each answer should leave the room as a decision, a deferred item or a disagreement, recorded with an owner. A decision record makes that possible. The facilitator writes it live, and participants can see it being filled in. The table below shows a shape that works for most sessions.

Leave disagreements visible. A disagreement written down as a disagreement is far more useful than one settled quietly by whoever spoke last, because it tells the design team where a configuration might be needed in two forms. Mapping those disagreements to the platform governance charter can help settle them.

Questions most programs skip and later regret

The standard question sets cover identification, ownership, controls and reporting. A few questions tend to be skipped, and they are the ones that cause rework later. Ask how long closed risks must remain visible, because retention rules decide how much history migrates and how the archive is searched. Ask who can see risks that concern a named individual, such as a conduct or investigation matter, because that answer often shapes the access model more than any other single choice. Ask what happens to a risk when the business unit that owns it is sold, merged or restructured, since the register will not follow the org chart unless someone decides how it should. Retention and archive decisions connect to audit trail evidence.

Ask also which external parties will read the register. An auditor, a regulator or a key customer may need a view that the internal team never uses, and building that view late is expensive. Confirm whether the external view should be a report, an export or a restricted login, and who approves it.

Sign-off sequence after the workshops

1. Circulate the decision record within a short window and invite corrections in writing.
2. Resolve every item marked open by its named owner before the design is frozen.
3. Walk the sponsor through the access model and the approval paths, asking for an explicit yes or no on each.
4. Confirm the reporting audience for each dashboard and the fields each audience needs.
5. Record the agreed design in the program’s own repository, with the version and the date of sign-off.

Signs that the workshop is not finished

A workshop has not done its job when participants leave still arguing about the basic definition of a risk, when no two people can name the same owner for the same statement, or when the most important risk discussed is absent from the register entirely. Each of these is a governance question dressed as a configuration question. Stop the design work, return to the sponsor and settle the governance question first. Continuing to configure around an unresolved definition can produce a system that needs rebuilding within the first review cycle.

Questions program teams ask after the workshops

How many workshops are enough?

Enough to cover each risk domain once, plus one session on cross-cutting concerns such as access and reporting. Repeat sessions often mean the first one left decisions open, which the decision record should have shown.

Should business users attend the technical design sessions?

Yes, for the questions that affect what people will click on. Keep the sessions on data flows and integration details to the technical leads, and report back to the business at the next session in plain language.

What if the sponsor cannot attend the sign-off?

Do not treat the design as signed until the sponsor or a delegate with the authority to decide has seen it. A design signed by a delegate who cannot make the escalation decisions is likely to be reopened later.

Can the workshop questions be reused for a second risk domain?

The structure can, and the answers cannot. A second domain shares the governance questions but usually has different owners, retention needs and external viewers, so the questions should be asked again with the new domain’s people in the room.