Moving to ServiceNow Integrated Risk Management: Migration Considerations

This guide helps an organisation decide what risk management it practises before moving to ServiceNow Integrated Risk Management. It covers the risk inventory, compliance alignment, legacy data mapping, which history to carry across, and reconciliation at cutover.

Assessing Current Risk Management Approach and Inventory

Before migrating to ServiceNow Integrated Risk Management, establish what risk management your organisation currently practices. Are risks formally registered and tracked, or do they exist informally in spreadsheets or email? Do you have a risk register by department, business unit, or centrally? What types of risks are tracked: operational risks, security risks, compliance risks, project risks, or a combination? Integrated Risk Management consolidates risk management across areas that may currently operate in silos. Understanding current fragmentation helps you design a unified approach and identify where consolidation creates the most value.

Conduct a comprehensive risk inventory by interviewing risk owners and business area leads. Record each risk with its description, owner, category (operational, security, compliance, strategic), likelihood, impact, mitigation status, and any control mechanisms currently in place. Understand which risks are interconnected or have cascading effects. Some organisations discover that multiple business units track the same risks independently; consolidating these reduces duplication and ensures consistent assessment.

Compliance Framework Alignment and Requirements Gathering

ServiceNow Integrated Risk Management supports different compliance frameworks (ISO 27001, NIST, SOX, GDPR, HIPAA). Your organisation may need to comply with several frameworks simultaneously, and each has its own risk assessment and control requirements. Before configuration, understand which compliance requirements drive your risk management. Align your Integrated Risk Management configuration with these requirements: risk categories, risk levels, control types, and reporting metrics should map to framework requirements. Compliance teams must be involved in defining these alignments; inadequate mapping creates audit gaps and reduces the value of risk data.

Understand whether you have existing compliance controls or assessments tracked elsewhere (ISMS documentation, audit findings, control matrices). Integrated Risk Management should become the system of record for controls, but you need a strategy for consolidating legacy control information into the new system. Some controls may be redundant or obsolete; this consolidation is an opportunity to rationalise your control environment.

Legacy System Data Migration and Mapping

If your organisation tracks risk in other systems (dedicated risk management tools, spreadsheets, business continuity platforms), data must be mapped and migrated to Integrated Risk Management. Export risks from legacy systems and map each to the matching ServiceNow risk, assessment, control and exception tables, using the names in the instance data dictionary. Review data quality as you migrate: are risk descriptions clear and actionable, or vague and generic? Do legacy risk assessments include evidence or justification for likelihood and impact scores? Are ownership and accountability clear, or ambiguous?

Risk assessment scales (likelihood and impact rating) may differ between legacy systems and ServiceNow. You may need to normalize or recalibrate scores during migration to ensure consistency. If your legacy system used a five-point scale and ServiceNow uses different values, decisions about how to map these are necessary; this is often a governance decision rather than a technical one.

Control information requires careful mapping as well. Controls in Integrated Risk Management link to risks and compliance requirements. If legacy controls are poorly documented or lack clear linkage to the risks they mitigate, this information must be reconstructed. This is labour-intensive but critical for the value of Integrated Risk Management. Control efficacy and testing results provide evidence that risks are actually being managed.

Cross-Module Integration and Related Processes

Integrated Risk Management integrates with multiple ServiceNow modules. Risks often trigger change management activities (mitigating controls may require infrastructure or process changes), create incident response requirements (if a risk materialises), and inform business continuity planning. Planning these integrations before go-live ensures data and workflows connect appropriately. For example, a risk assessment that identifies inadequate security controls should trigger a change request to implement security enhancements.

Security Risk Management integration requires coordination with your security team. If your organisation uses GRC (Governance, Risk, Compliance) for security incident tracking, this must integrate with Integrated Risk Management. Business Continuity Planning should reference risks to ensure recovery procedures address identified risks. Strategic planning teams should use risk assessments to inform resource allocation decisions. Without these integrations, Integrated Risk Management becomes an isolated tool rather than an operational decision-making system.

Stakeholder Engagement and Governance Structure

Integrated Risk Management success depends on stakeholder engagement. Risk owners throughout the organisation must contribute risk information, update assessments regularly, and implement mitigation activities. Define clear governance: who has authority to declare a risk closed, who escalates emerging risks, who sets risk tolerance levels for different areas, how frequently assessments must be updated. Establish a risk committee to oversee the process and escalate significant risks to executive leadership.

User training and change management are often underestimated. Risk owners may be unfamiliar with ServiceNow or risk assessment methodologies. Provide training tailored to role: executives need to understand risk dashboards and summary reporting, risk owners need to know how to create and update risk records and track mitigations, compliance teams need to understand how controls link to risks and how to demonstrate compliance. Change communication should explain why Integrated Risk Management improves current risk management and how it changes workflows for each audience.

Deciding what history to carry across and what to leave behind

A legacy risk register rarely deserves a full copy. It holds three kinds of material mixed together: live risks that someone still manages, closed risks that matter only for the record, and stale entries that were never cleaned up. Each kind needs a different treatment. A program manager who moves everything unchanged will import the stale entries as if they were current, and the new platform will then report exposure that nobody actually owns. Sorting comes first, and it is not a technical task.

The table sets out the usual treatment for each category of legacy data. The reasons column matters more than the treatment column, because it is what a future auditor or a new platform owner will ask about.

Converting scores without inventing precision

Score conversion is where migrations quietly lose meaning. A legacy scale of five levels does not map neatly onto a new scale of a different width, and a simple numeric conversion creates false precision. The safer method is a crosswalk: a written table that says which legacy level corresponds to which new level, signed off by the risk committee and kept with the migration file. Where two legacy levels fall into one new level, record that they were merged, so the loss of detail is visible rather than hidden.

Plan the wider rollout order with the implementation roadmap so the register cutover does not land in the middle of an unrelated phase. Keep a small sample of scores that were recalculated by hand, and compare them with the converted values. If the converted values disagree with the hand calculations in a pattern, the crosswalk is wrong, not the data. Fix the crosswalk and re-run the sample before going further.

A reconciliation sequence for the cutover window

Reconciliation is easier to manage as a sequence than as a pile of checks. The order below keeps each step’s output usable by the next one.

1. Freeze the legacy register for the scope being moved, and record the freeze date and the person who approved it.
2. Export the register with its owners, scores, dates and attachment references, and keep the export unchanged as the reference copy.
3. Apply the taxonomy and merge duplicates in a working copy, logging each merge with its reason.
4. Run the score crosswalk and sample-check a set of hand-calculated risks against it.
5. Import a test batch into a non-production instance and confirm owners, linked controls and closed status arrived unchanged.
6. Compare record counts by status with the reference export, and explain every difference before the production import.

Step six is the one teams often skip under schedule pressure. A count that differs by a few records is often explicable, but an unexplained difference is the first sign of a silent loss, and it should stop the cutover until it is understood.

When not to migrate at all

Some legacy material should not move. Risks that were retired because the underlying activity stopped, and risks duplicated in another register that is staying in service, are the common examples. Keeping them in the new platform clutters the views people use every day. A read-only archive, linked from the new platform where the record is needed for an audit query, often serves better than a full migration. Agree the archive rule with the audit function before the freeze, because an auditor who finds a missing record later will ask why it was not kept. Evidence trails for those archived records are covered in the note on audit trail evidence.

A team that cannot say who would own a migrated risk after cutover should not migrate that risk as live. That gap is an ownership problem, and importing it only moves the problem into a system that reports on it more prominently.

Questions teams ask before a register migration

Should we migrate evidence files along with the risk records?

Only where the storage location is stable and the file can be opened from the new platform. Test a sample of links after the test import, building on the testing and acceptance checklist as a starting point. Where links fail, record the failure against the risk and decide whether to re-attach the evidence or mark the control as not yet evidenced.

Can we migrate the old scores and then recalculate them?

Recalculation is appropriate only if the new scoring rules are approved and the owners have reviewed the result. Recalculating silently changes a risk’s apparent trajectory. Record the old score, the new score and the reason for the change on each record.

How long should the legacy register stay accessible?

Keep it accessible for as long as your audit and retention policy requires for the periods it covers. The decision belongs to the records owner and the audit function, not to the migration team, and it needs a line in the cutover plan.

Who should approve the crosswalk?

The risk committee, or whichever body owns the risk scale. A crosswalk approved only by the migration team tends to be challenged later, when a score that moved between levels becomes material.