---
title: "Risk Register and Issue Log Template (IDK-04)"
date: 2026-09-21
description: "Ready-to-use template IDK-04: Risk Register and Issue Log for IFS Cloud implementation projects, aligned with the IFS implementation methodology."
author: "Dariusz Mysliwiec"
categories:
  - name: "Implementation docs kit"
    url: "https://www.ifs-erp.com/implementation-docs-kit.md"
---

# Risk Register and Issue Log Template (IDK-04)

Template IDK-04, version 1.0. Phase: All phases.

 ## How to use this template

 
- Set it up during Initiate Project and keep it alive until the closure document is signed. A register that is only opened before a steering group meeting is a report, not a control.
- The customer project manager owns it. The supplier project manager contributes risks from the delivery side. Every team member may raise an entry.
- Section 4 is starter content: risks that recur in ERP implementations. Keep the ones that apply, rewrite them for your project, delete the rest. Do not present the starter list as your risk analysis.
- A risk is something that may happen. An issue has happened. When a risk occurs, close it in the register and open it in the issue log with a reference.
- It is done for the first gate when the scales are agreed, every open risk has one named owner and a response, and the escalation rule in section 6 is accepted by the steering group.

 | Field | Value |
| --- | --- |
| Template ID | IDK-04 |
| Phase | All phases |
| Owner | Customer project manager (with supplier project manager support) |
| Approver | Steering group |
| Qualification gate | Project Initiated (register and process in place); reviewed at every later gate |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Risk process](#1-risk-process)
- [2. Scales](#2-scales)
- [3. Rating matrix](#3-rating-matrix)
- [4. Risk register](#4-risk-register)
- [5. Issue log](#5-issue-log)
- [6. Escalation rule](#6-escalation-rule)
- [7. Review rhythm](#7-review-rhythm)
- [Approval](#approval)

 ## Document control

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [name, role] | Process, scales and starter register |   |
| 1.0 | [YYYY-MM-DD] | [name, role] | Baseline for gate Project Initiated | [steering group chair] |

 ## 1. Risk process

 | Step | What happens | Who | When |
| --- | --- | --- | --- |
| 1. Identify | Risks are collected in workshops, in the weekly project team meeting and from each phase review. Each is written as cause, event, effect: "Because [cause], [event] may happen, leading to [effect]." | Anyone; logged by the PMs | Continuous |
| 2. Assess | Probability and impact are rated with the scales in section 2. The rating comes from section 3. | PMs with the person who raised it | Within [agree in project] of logging |
| 3. Plan response | One response type is chosen: avoid, reduce, transfer, accept. For reduce: concrete actions. For accept: a stated trigger and a fallback. | Risk owner | Before the next project team meeting |
| 4. Assign and act | One named owner per risk. Actions enter the project plan with dates, like any other task. The owner reports progress; the PMs check that actions are actually performed. | Risk owner, PMs | Reviewed weekly; top risks at every steering group |

 Closing a risk requires a reason: occurred (moved to issue log), no longer possible, or reduced to a level the steering group accepts.

 ## 2. Scales

 Ratings are described in words so that two people rate the same risk the same way.

 
### 2.1 Probability

 | Rating | Meaning |
| --- | --- |
| Low | Would surprise the team. No sign of the cause today. |
| Medium | Could reasonably happen. The cause is present but under some control. |
| High | Expected to happen unless something changes. Early signs are already visible. |

 
### 2.2 Impact

 | Rating | Schedule | Cost | Solution quality and business operation |
| --- | --- | --- | --- |
| Low | Absorbed inside the phase; no milestone moves | Absorbed inside the workstream budget | Inconvenience; a workaround exists and users accept it |
| Medium | A milestone moves but the gate date holds | Needs contingency released by the sponsor | A process works with a manual step, or a benefit is delayed |
| High | A gate or the go-live date moves | Needs a budget decision by the steering group | A business-critical process cannot run, or data cannot be trusted |

 Project-specific definitions agreed for this project: [add or adjust].

 ## 3. Rating matrix

 | Probability \ Impact | Low | Medium | High |
| --- | --- | --- | --- |
| High | Moderate | Major | Critical |
| Medium | Minor | Moderate | Major |
| Low | Minor | Minor | Moderate |

 | Rating | Handling |
| --- | --- |
| Critical | Reported to the steering group with a response plan. Owner at sponsor or steering group level. |
| Major | In the top-risk list of the status report. Owner at PM or process owner level. |
| Moderate | Managed by the PMs. Reviewed weekly. |
| Minor | Logged and reviewed at each phase end. |

 ## 4. Risk register

 Columns: P = probability, I = impact. Status: open, reducing, accepted, occurred, closed.

 
### 4.1 Project-specific risks

 | ID | Raised | Risk (cause, event, effect) | Area | P | I | Rating | Response type | Response actions | Owner | Next review | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: R-101 | [YYYY-MM-DD] | Because supplier and part data sit in two legacy systems with different numbering, duplicate suppliers may be loaded, leading to split purchase history and wrong payment terms on purchase orders | Data, procurement | High | Medium | Major | Reduce | Procurement data steward merges duplicates in the source before load cycle [n]; match rule agreed; validation query run after every load in Data Migration Manager | Procurement data steward | [YYYY-MM-DD] | Reducing |
| Example: R-102 | [YYYY-MM-DD] | Because warehouse roles are defined late, the acceptance test may be run with broad permission sets, leading to access problems discovered only at go-live | Security, inventory | Medium | High | Major | Reduce | Functional roles for warehouse drafted before the security-and-data test cycle; testers log in with end-user permission sets only | Technical analyst, security | [YYYY-MM-DD] | Open |
| [ID] | [YYYY-MM-DD] | [risk] | [area] | [P] | [I] | [rating] | [type] | [actions] | [name] | [YYYY-MM-DD] | [status] |

 
### 4.2 Starter content: risks that recur in implementation projects

 Listed roughly from most to least damaging. Rate each for your own project; the P and I columns are left empty on purpose.

 | ID | Risk | Typical early sign | Response that works | P | I | Suggested owner |
| --- | --- | --- | --- | --- | --- | --- |
| S-01 | Senior management is not visibly committed | Steering group members send deputies; decisions wait | Steering group members act as champions in their own areas; attendance and decisions are minuted |   |   | Executive sponsor |
| S-02 | The wrong people are on the team, or the right people are not released | Workshops attended by whoever is free; core team answers operational calls during sessions | Key people with authority to decide; backfill agreed in writing ([IDK-03](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/03-project-organisation-and-raci) section 6); extra capacity planned for peaks |   |   | Executive sponsor |
| S-03 | Project management is weak | Plan not updated; same issues reappear; meetings without actions | Realistic plans; plan, do, review cycle per team every week; short whole-team stand-up; risks and issues worked actively |   |   | Both PMs |
| S-04 | Scope grows without decision | "Small" additions agreed in workshops; consultants building undocumented items | Scope baselined in the plan and scope statement and signed by the steering group; every change documented and communicated ([IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure)) |   |   | Both PMs |
| S-05 | Pressure for modifications and for keeping legacy interfaces | Requests to make the new system look like the old one | From the first day, modifications and integrations need steering group authorisation; standard functionality is tried first |   |   | Steering group |
| S-06 | Resistance to change | Rumours, low workshop engagement, requests driven by habit | Communication strategy and plan; messages about benefits for each group; the system is not modified to soothe users |   |   | Change lead |
| S-07 | Other projects compete for the same people and attention | Core team pulled into other initiatives | Sponsor keeps this project among the top business priorities and resolves conflicts at steering group |   |   | Executive sponsor |
| S-08 | The solution does not meet the need or the quality expected | Tests designed only by the project team; decisions not reviewed | Right team; test design involves the wider business; steering group reviews major decisions; unit tests, then end-to-end tests by the team, then by end users |   |   | Customer PM |
| S-09 | Data migration fails or arrives late | Data sources unknown; cleansing not started; first load attempted late | Identify data and sources early; start cleansing early; documented strategy; trained technical team; several full load iterations |   |   | Customer data lead |
| S-10 | End users are not trained or do not accept the solution | No training plan; trainers not named | Plan who is trained, in what, when and by whom; train the trainer; expert users teach their colleagues |   |   | Customer PM |
| S-11 | Go-live fails | Cutover plan exists only in the supplier's head; no rehearsal | Documented and approved cutover plan; rehearsed more than once with full data volumes; rollback plan with a point of no return |   |   | Both PMs |
| S-12 | Teething problems after go-live overwhelm the business | Help desk unprepared; no local presence | Training that shows each user what they personally gain; support present on site; expert users as first contact; help desk trained in basic administration |   |   | Customer PM |
| S-13 | Benefits are not realised | Business case not looked at after approval | Time-bound benefits in the business case; sponsor accountable; reviewed at every steering group |   |   | Executive sponsor |
| S-14 | Tailoring blocks future updates | CRIM log grows; no one asks how objects behave at the next release update | Update cadence discussed at project start; technical solution manager reviews each CRIM item for update impact |   |   | Technical solution manager |

 ## 5. Issue log

 An issue is a fact that needs action now. It has a priority, not a probability.

 | Priority | Meaning |
| --- | --- |
| High | Stops a workstream or threatens a milestone. Needs a resolution path within [agree in project]. |
| Medium | Slows work; a workaround exists. |
| Low | Does not affect the plan. Fixed when convenient. |

 | ID | Raised | Raised by | Issue description | Area | Priority | Impact if unresolved | Owner | Agreed action | Due | Status | Resolution and date | Linked risk or change request |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: I-014 | [YYYY-MM-DD] | Functional team lead, procurement | Approved authorisation rules for purchase requisitions differ between the two companies; the Book of Rules assumes one rule set | Procurement | High | Prototype scenario for requisition approval cannot be finalised | Head of procurement | Decide on one rule set or document both; decision paper to PMs | [YYYY-MM-DD] | Open |   | [CR reference if raised] |
| Example: I-015 | [YYYY-MM-DD] | Technical analyst, integrations | Third-party transport system has no test instance available for integration testing | Integrations | Medium | Integration INT-03 tested late, risk to acceptance test entry | Customer IT lead | Request test instance from vendor; interim test with recorded messages | [YYYY-MM-DD] | In progress |   | R-[n] |
| [ID] | [YYYY-MM-DD] | [name] | [issue] | [area] | [priority] | [impact] | [name] | [action] | [YYYY-MM-DD] | [status] | [resolution] | [reference] |

 Defects found in testing are not logged here. They live in the test tracker with their own classification (cause, blocks deployment, contractual, owner, closure date). Only a defect that threatens a milestone is lifted into this log.

 ## 6. Escalation rule

 | Situation | Escalated to | By | How fast |
| --- | --- | --- | --- |
| Risk rated Critical, or any risk whose response needs budget, scope or date change | Steering group | Both PMs, through the sponsor | Next steering group; extraordinary meeting if the decision cannot wait |
| High-priority issue not resolved by its due date | Executive sponsor | Customer PM | [agree in project] |
| Issue where the two PMs disagree | Both sponsors | Either PM, after telling the other | [agree in project] |
| Issue blocked by a person or department outside the project | Executive sponsor | Customer PM | [agree in project] |
| Any issue whose resolution changes a baseline | Change control ([IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure)) | Issue owner | Before work continues |

 An escalation is written: the issue, the options considered, the recommendation, the decision needed and the date it is needed by. Putting it in writing often settles it before the meeting.

 ## 7. Review rhythm

 | Review | Participants | Scope |
| --- | --- | --- |
| Weekly project team meeting | PMs, workstream leads | New entries, overdue actions, Major and Critical risks, High issues |
| Steering group | Steering group | Top risks and issues, escalations, trend since last meeting |
| Phase review | PMs, sponsors | Full register; lessons feeding the next phase |

 ## Approval

 | Name | Role | Date | Signature |
| --- | --- | --- | --- |
| [name] | Executive sponsor (customer) | [YYYY-MM-DD] | ______________________ |
| [name] | Customer project manager | [YYYY-MM-DD] | ______________________ |
| [name] | Supplier project manager | [YYYY-MM-DD] | ______________________ |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.