A project risk register is a place to record what might disrupt delivery while there is still a decision to make about it. For a small creative studio, the useful entry is rarely “the project could be late”. It is the specific uncertainty, the warning you will watch for, the person who will respond and the date when the team will look at it again.
This project risk register template is for freelancers and studios handling ordinary client work: copy, design inputs, review decisions and delivery dates. It is a manual planning record, not a specialist safety, legal or cyber-security assessment. It does not predict an event or show that a response has reduced its probability.
Download the project risk register (CSV) and the risk review note and fictional completed example (TXT). Replace the examples with your own project information. Keep confidential references in their agreed location rather than copying private client material into every row.
Record a possible event, not a general worry
Describe the event in a way that someone else can recognise. “Final copy may arrive after the agreed input date, leaving too little time for the first layout” gives the team something to discuss. “Client communication” is a topic, while “the deadline has already passed without the copy” describes a problem that now needs action. A useful register distinguishes those states.
The Australian Government’s risk management planning guidance, checked on 22 October 2026 Australian time, considers likelihood and consequence, then treatment responsibilities, timeframes and future checks. This guide applies those ideas to routine client delivery. It does not reproduce the government’s example scoring scale or turn an editorial judgement into a measured probability.
Begin with a small number of uncertainties connected to the work that matters next. Ask what could stop the next meaningful commitment, what the consequence would be and whether anyone can still influence it. A long list of remote possibilities can hide the decision the team actually needs to make this week.
Separate a risk, an early signal and an issue
A risk is the event that may happen. An early signal is something you can check that suggests the situation needs attention. An issue is something that has happened and needs a current response. The same project may need all three records, but they should not be interchangeable labels for “something is wrong”.
| Record | Illustrative wording | What the team does with it |
|---|---|---|
| Possible event | Final copy may arrive after the agreed input date | Name a response owner and decide what to check before then |
| Early signal | The client reports that the copy approver is still undecided at the agreed checkpoint | Discuss the response while the input date is still ahead |
| Issue that has occurred | The agreed input date has passed and approved copy has not arrived | Record the actual problem and agree the next delivery decision |
Set the signal in language that the owner can use. “Watch closely” does not identify what to watch or when. A named checkpoint, an unanswered decision or an input the client says is not ready can be more useful. A signal is not proof that the feared event will happen, and its absence is not proof that delivery is safe.
If the event occurs, link the register entry to the team’s current issue or action record. Keep the original risk reference so the history still makes sense. Do not leave a missed input described only as a possibility while the schedule is already affected. Equally, do not mark every warning as an occurred issue without checking what actually happened.
Use fields that support a decision
The CSV keeps the possible event, consequence, evidence, signal, response and review date separate. You can remove a field that is genuinely irrelevant, but keep enough information for another collaborator to understand why the entry exists. A risk title alone will not tell a covering designer which conversation to have.
- Name the client project and give the entry a reference that will survive a change in wording.
- Describe the possible event and its practical effect on a delivery commitment.
- Record the information you have and what remains uncertain.
- Explain why the team is considering it now, using human judgement rather than an invented percentage.
- Set a checkable early signal and the point when someone will check it.
- Name a preventive action and the response to discuss if the event happens.
- Agree one coordinating owner, an action due date and a separate next review date.
- Keep the current state, decision and evidence reference up to date.
Make the consequence specific without making it dramatic. Late copy may affect the layout sequence; an undecided reviewer may leave a proof without an authorised response. Describe the commitment that could be affected rather than assuming lost revenue, a damaged reputation or a particular number of wasted hours.
Prioritise with a reason, not a decorative score
Ask two different questions: how plausible does the event appear from the information available, and what would happen to the work if it occurred? An uncertain likelihood does not remove a serious scheduling dependency. A plausible event may still have a manageable consequence if the team has already agreed an alternative.
This worksheet uses a written priority reason instead of multiplying ratings. “Review before the first layout because approved copy is an input” is a reason someone can challenge. If your organisation already uses defined ratings, keep their definitions and record who made the judgement. Do not present a label such as “high” as a measured forecast or compare unexplained scores between projects.
Record an unknown rather than guessing. You may need to ask the client who can approve the copy before you can judge the situation. That information-gathering task can be the next useful action. The register should expose uncertainty, not make it disappear behind a colour or number.
Agree the response and the person who will coordinate it
A preventive action is something you can do before the event. A response is what you would discuss or carry out if it occurs. They may involve different people and different approvals. Preparing a named proof-request format is within a studio’s control; changing a client’s review window usually needs that client’s agreement.
| Possible delivery event | Preventive action to consider | Response if it occurs |
|---|---|---|
| Approved copy arrives after its input date | Confirm the copy owner and approval route before the checkpoint | Agree the affected sequence and revised commitment with the client |
| Feedback comes from people with conflicting instructions | Ask who will consolidate the response and name the version under review | Pause that disputed decision and obtain one agreed instruction |
| A required image is unavailable in the agreed format | Check the file requirement and the person supplying it before layout | Discuss an authorised alternative or the affected output before proceeding |
These are examples to adapt, not automatic instructions for a live project. The owner coordinates the check and the next decision; the title does not give them authority to change the scope or promise a new date. Record whose agreement is needed and where that agreement will be kept.
Keep the action due date distinct from the risk review. Confirming an approver may be due before the team next examines the risk. If the action is late, record that state instead of moving the review date to make the register look current. If the project changes, revisit both dates and the reason for them.
A fictional studio records a copy-delivery risk
The completed note below is an invented illustration. Birch Relay Studio, Tidal Press, Mina, Theo and every reference and date are fictional. It is not a customer record, an observed probability or evidence that the planned response has worked. The copy deadline is still in the future at the example’s review date.
Project and entry: Tidal Press product leaflet, reference TP-LEAFLET; risk DR-01. Current note dated 22 October 2026.
Possible event and consequence: Approved copy may arrive after the agreed 30 October input date, affecting the first layout planned for 3 November.
Information and uncertainty: The team has an agreed input date but has not confirmed who will approve the final copy. It does not know how likely a delay is.
Priority reason: Review this before layout preparation because approved copy is a required input. This is the fictional team’s judgement, not a numerical risk rating.
Early signal: At the 27 October checkpoint, ask whether the client has confirmed the copy approver and whether the agreed input date remains achievable. An unresolved answer calls for discussion; it is not proof of a missed deadline.
Prevention and owner: Mina will confirm the copy owner and approval route by 26 October. Theo will record the agreed reference in the project notes.
If the event occurs: If the input date passes without approved copy, record the occurred issue and discuss the affected layout sequence with the client before agreeing a revised commitment.
Next review and current state: Mina reviews DR-01 on 27 October 2026. Open, response planned; the event has not occurred in this example. No reduction in likelihood has been established.
The planned action does not guarantee that copy will arrive. It gives Mina a specific conversation and a checkpoint before the input date. If the client confirms a different arrangement, the team should record that new information and reconsider the entry rather than preserving the original description merely because it is already in the spreadsheet.
Review the entry when the situation changes
At the next review, record what changed, whether the action was completed and whether the response is still appropriate. Keep the evidence reference rather than recording only “discussed”. An unchanged risk may still need attention; a closed entry should explain why the event no longer applies or which current issue record replaced it.
Use a weekly update to communicate an agreed decision, not as a substitute for the register’s reasoning. The client status report template can help identify the decision needed from the client. The project timeline guide can help make the affected dependency visible; adapt it to the actual job rather than copying a website schedule.
After the project, a learning review can examine which warnings were useful and which responses fitted the work. That is a different question from the live register’s next decision. Do not claim that an uneventful project proves the register prevented a delay, or that one missed event makes every previous judgement wrong.
You can put the agreed preventive action and next review into TASKUL as separate tasks against the client project, with an owner and date. Keep the risk entry and its evidence in the team’s agreed document location. This is manual follow-through, not a TASKUL risk engine, AI assessment, automatic monitoring or email promise. The register earns its place when the team knows what it is watching and who will act next.
