Risk and issue register update

Purpose

Bring a project RAID register up to date from current evidence. It distinguishes new risks, changed scores, active issues, closed items, dependencies, and overdue mitigations so the project status is decision-ready.

Scope

Assess the current register, project status report, workstream updates, action log, decision log, dependency map, change log, and prior register snapshot.

Excluded: accepting a risk, closing an issue without evidence, assigning an owner or due date, and changing the source register.

Data basis

• Current and prior RAID register with ID, type, description, probability, impact, score, owner, mitigation, trigger, target date, and status.
• Weekly status report, workstream reports, action and decision logs, dependency map, and change requests.
• Project scoring matrix, escalation thresholds, and closure criteria.

Result

A register update sheet with record-level changes and citations, plus a status memo showing new, escalated, overdue, closed, and unconfirmed items.

Quality criteria

• Every changed field cites current evidence and every closed item cites closure evidence.
• Scores reproduce from the supplied probability-impact matrix.
• Risk, issue, assumption, and dependency types remain distinct.
• No owner, date, mitigation, or status is invented.

Instructions

Use the current register ID as the primary key. Prefer explicit project evidence over inferred sentiment and retain prior values when the current source is silent. Recalculate score only when both probability and impact are available. Apply escalation thresholds from the project rubric. Treat a mitigation as overdue only against its stated target date and current period. Preserve the old and new values for every changed field.

Adapt before use

• Add the current and prior RAID registers and map their fields.
• Define the probability-impact matrix, escalation bands, closure evidence, and review date.
• Map project owners, workstreams, status labels, and dependency identifiers.

Process detail

Set the reporting cut-off

Record the status date, project phase, reporting audience, and source freshness for each update file.

Data basis: Run input, status report headers, register snapshot dates, and project calendar.

Result: A cut-off register showing which evidence is current.

Acceptance criterion: Every source is accepted or marked stale relative to the cut-off.

Exception: Do not use a future-dated update as current evidence.

Reconcile register identities

Match current and prior records by RAID ID, then classify new, missing, renamed, and duplicate IDs.

Data basis: Current register, prior register, and change log.

Result: Identity bridge preserving prior and current IDs.

Acceptance criterion: Each prior record has one disposition and each current record has one identity status.

Exception: Keep possible merges unresolved when descriptions or IDs conflict.

Update evidence fields

Extract current description, trigger, consequence, owner, mitigation, target date, dependency, and status from reports and logs.

Data basis: Current register, status reports, action log, decision log, and workstream updates.

Result: Evidence-backed field update table with source locations.

Acceptance criterion: Every changed field has a current citation; unchanged fields retain their prior value.

Exception: Record not evidenced when the current corpus is silent rather than copying an assumption.

Recalculate score and escalation

Apply the probability-impact matrix, compare score with escalation bands, and classify movement from the prior snapshot.

Data basis: Current probability and impact, project scoring matrix, prior score, and escalation rules.

Result: Risk score and escalation table with old/new values.

Acceptance criterion: Each calculated score can be reproduced from two inputs and the matrix citation.

Exception: Leave score unassessed when probability or impact is missing or qualitative without mapping.

Test actions, closures, and dependencies

Identify overdue mitigations, unsupported closures, blocked dependencies, and issues lacking a current next action.

Data basis: Mitigation target dates, closure criteria, dependency map, decision log, and current date input.

Result: Exception queue and executive status summary.

Acceptance criterion: Every overdue or closed finding cites the relevant action, criterion, or dependency row.

Exception: Do not close a record solely because it disappeared from a weekly report.

Document what could not be assessed

List stale sources, duplicate IDs, missing scores, absent owners, unverified closures, and unresolved merges.

Data basis: Identity bridge, update table, and exception queue.

Result: Open-points section with RAID ID and evidence gap.

Acceptance criterion: Every open point names the affected ID and source location or missing source.

Exception: State no open points only after all current and prior IDs are compared.