Project risk management for client work: a practical risk register

Manage uncertainty with actions, not a list of worries

Project risk management means identifying uncertain events, assessing their possible effects and deciding who will act before or when they occur. A useful small-studio risk register connects each risk to an owner, a practical response, an observable trigger and a review date. It should help you make delivery decisions, not merely document that you were concerned.

The Highway Knowledge Portal describes project risk as uncertainty that can affect outcomes positively or negatively. Its guidance covers identification, prioritization, ownership, response and monitoring. This guide adapts those general principles to freelance client work and concentrates on threats to delivery; it does not apply highway-project rules to a studio.

Separate a risk, an issue and an assumption

“The approver may become unavailable during review” is a risk. “The approver has cancelled and no replacement is appointed” is an issue: it has happened. “The approver will be available on Tuesday” is an assumption supporting the plan. Test important assumptions and record the risk if they might prove false.

Write risks as cause, uncertain event and consequence: “Because only one client contact can authorize release, an absence during review could delay approval and miss the booked handoff.” That is more actionable than “client problems.” Avoid assigning blame or filling the register with unsupported character judgments.

When a risk occurs, link it to an issue with a current action owner and forecast impact. Preserve its history, but stop describing the occurred event as merely possible. Further consequences can remain uncertain: an overdue input is an issue, while losing a future production booking may still be a risk.

Choose simple ratings with stated meanings

Start with qualitative likelihood and impact. For the fictional example below, likelihood 1 means unlikely given current evidence, 2 means plausible, and 3 means likely unless action changes the situation. These are judgment labels, not measured probabilities. Note the evidence behind each rating.

The example uses schedule impact 1 for at most one working day, 2 for two to three working days, and 3 for more than three working days or missing the fixed release window. These thresholds are illustrative choices for this project, not industry benchmarks. Cost, security or quality consequences need their own description and may require urgent action regardless of schedule impact.

Likelihood multiplied by impact gives a rough sorting aid: 2 × 3 = 6, for example. It is not an expected delay, monetary loss or mathematically precise comparison. Consider urgency and interdependence as well. A serious confidentiality risk should not be ignored because its likelihood rating is low.

Worked risk register: a client research report

This fictional register is reviewed on October 9, 2026. A studio is preparing a research report for release on October 23. All dates and ratings are illustrative, and the team has agreed the working calendar. None of the three risk events below has occurred at the review date.

R-01 | Cause and event: one client approver may be unavailable during final review | Consequence: approval could miss the fixed release window | Likelihood 2, impact 3, score 6 | Evidence: backup authority is not yet confirmed | Owner: Sal, studio producer | Mitigation: ask client sponsor Inez to appoint an authorized backup by October 12 | Trigger: no backup confirmation by 12:00 UTC on October 12 | Response: Sal escalates to Inez that day to agree a review arrangement or revised release plan | State: open | Next review: October 12.

R-02 | Cause and event: an untested client data export may omit fields needed for the report | Consequence: two to three working days of correction and renewed analysis | Likelihood 2, impact 2, score 4 | Evidence: no representative sample has been checked | Owner: Dev, studio analyst | Mitigation: validate a sample against the agreed field list by October 13 | Trigger: a required field is absent or unusable in the sample | Response: Dev requests a corrected export from client data owner Mei and updates affected analysis dates | State: open | Next review: October 13.

R-03 | Cause and event: the sole layout contractor may become unavailable during production | Consequence: more than three working days of delay if no replacement is ready | Likelihood 1, impact 3, score 3 | Evidence: booking is confirmed but no alternate is briefed | Owner: Sal | Mitigation: confirm an alternate and prepare a limited, securely shared handoff brief by October 14 | Trigger: primary contractor reports inability to meet the booking | Response: Sal checks alternate availability and seeks budget authorization before a replacement booking | State: open | Next review: October 14.

The scores are 6, 4 and 3. That supports discussing R-01 first, but does not justify postponing the sample check needed to prevent rework. These possible delays are not added together as a forecast: the events may not happen, and their consequences may overlap.

Distinguish prevention from the response after a trigger

Mitigation changes likelihood or impact before the risk occurs. A contingency response describes what to do if the trigger is reached or the event happens. Naming a backup reviewer is mitigation; escalating when no backup is confirmed is a triggered response. A trigger can be an early warning rather than proof that the whole risk has materialized.

Avoidance removes the exposure by changing the approach, subject to agreement. Transfer allocates a defined exposure to another party, such as through suitable insurance or contract terms; it does not make every operational responsibility disappear. Acceptance means deliberately retaining a risk, with an owner and any agreed response resources, rather than forgetting it.

Reserve any response time or money once in the relevant plan. If two risks need the same backup specialist, check that the proposed responses can coexist. Record residual risk after completed mitigation; do not lower a rating just because someone wrote an action that has not yet happened.

Copy this register structure and keep it current

A document or spreadsheet is enough when the team can find the current record. Use one entry per distinct uncertain event and keep sensitive internal details out of client-facing copies. Share the delivery consequence and decision the client needs, not private speculation.

1. Identity: risk ID, date raised, cause, uncertain event and affected objective.
2. Assessment: evidence, likelihood, impact description, priority and assessment date.
3. Ownership: one accountable risk owner; action owners and any required decision maker.
4. Prevention: mitigation action, due date, resources and completion evidence.
5. Response: observable trigger, contingency action, authority needed and escalation route.
6. Review: next check, action progress, residual exposure and state: open, occurred, accepted or closed.

Close risks for a reason, not because the register is old

Review the register at relevant checkpoints and whenever an assumption changes. Close an entry when exposure has ended or the risk is no longer applicable, recording why. An accepted risk still needs monitoring while exposure remains; an occurred risk needs issue management.

For higher-consequence legal, privacy or security exposure, involve the appropriate qualified adviser rather than relying on this lightweight scoring example. The aim is proportionate attention: visible uncertainty, timely decisions and realistic response plans, not a promise that every setback can be prevented.