Keep a risk and issue log the team can review

Decide what the log is for

A risk and issue log is the list you keep between updates. Use it when someone needs to see what might happen, what has already happened, who will respond, and when you will look again. It is not a status colour, and it is not a transcript of the meeting.

There is no browser editor for this log. The risk and issue log template is an editable Word file, an editable Excel file, and a printable PDF. The PDF is a blank layout, not a form. Keep Excel as the source. Make a Word or PDF copy only when you need a reading version.

The project status report tool has a shorter Risks and decisions table for this reporting period. It is not a substitute for the log. The status report guide covers the narrative; this one covers the longer record and the column mapping.

Separate a risk from an issue

Use Type for one of two words, and write that rule in Scope / escalation rules so the next editor does not invent a third category.

The vague line “Testing is a concern” is neither. It does not say whether the problem is already here, which work it affects, or what changes if nobody acts. The template does not score likelihood or impact. If you use a score, define it in the header and type it in the description. The workbook will not calculate it, and it will not run a formula.

When a risk happens, do not delete R-04 and create a new I-09 that looks unrelated. Keep the ID, change Type from Risk to Issue, and add a dated sentence to the response: “Occurred on 9 October; previously tracked as a risk.” A reviewer can then see that the item moved, instead of treating it as new work.

Fill the blank, then lift a decision into the report

1. Open the issue log template. The downloads work without JavaScript. Use Excel for the list you will update, Word when this review needs a short narrative, and the PDF only to print an empty layout. The PDF is not a form you can complete in the browser.
2. Fill the header before the first row. Project name identifies the work. Review date is the day you are reviewing the whole log, not the due date of one item. Log owner is the person who keeps the file current. Scope / escalation rules says which items must be raised outside the log, for example anything that moves the next milestone.
3. Add a row only when the item changes someone’s work. Give it a stable ID, such as R-01 or I-01. Write Description / impact as the affected work plus the consequence. Name one Owner. Write Response as the next action or the decision you need, not the word “monitor” on its own. Put the next checkpoint in the row’s Review date. Set Status with the vocabulary you wrote in the header, such as Open, In progress, or Closed.
4. When you write the weekly status report, open the status report tool. In Basics, set the reporting period so it matches the evidence. In Track, use Add row on Risks and decisions only for items that need a decision in that period.
5. Copy the meaning, not the spreadsheet shape. The tool’s columns are Risk or issue, Owner, Response / decision needed, and Review date. It has no ID, Type, or Status column. Leave the ID in the log. Shorten the description so it still states the effect.
6. Choose Review & export. The checks flag empty details. They do not confirm that the risk is real or that the owner agreed. Download Word or Excel, or use Print / save PDF and choose Save as PDF in the browser dialog. That button does not download a PDF by itself.

A fictional log row: I-01, Issue, “Payment sandbox unavailable; six cases have not started, so the 16 October launch cannot be confirmed.” Owner Sam Lee. Response “Restore the sandbox or confirm a fallback by 12 October.” Review date 2026-10-12. Status Open. The status-report row keeps the effect, Sam Lee, the decision, and that date. It drops the ID and the type.

Common mistakes, and the correction

Edge cases that change the row

A risk expires without happening. Close it. In Response, say “Did not occur by 16 October; no further action.” Do not leave it Open because it once looked serious.

The owner leaves. Keep the ID. Change Owner and add the handover date in Response. Do not start a second ID for the same sandbox outage.

You need a score or a corporate register column. The blank has neither. Add columns only in your own copy of the Excel file, after the team has agreed what they mean. The status report tool still accepts only four cells on a Risks and decisions row.

The description is long. Excel will store a long note. The status report tool will not: 600 characters per cell and 2,000 per main field. An oversized value is rejected, not silently cut. Keep the short decision in the tool and the long note in the log.

More than 50 decision items. Risks and decisions stops at 50 rows. Bring forward only items that change this period, or split the report. The log spreadsheet is not capped at 50 by WorkFormKit.

Someone wants a heat map or an email when a date passes. This download does not send mail, colour cells, or read a calendar. A date in the sheet is text you agreed, not a reminder.

What this log will not do

• It will not tell you whether the item is actually a risk. Type is a word you choose. The template does not enforce “Risk” or “Issue”.
• It will not sync with the status report, the minutes, or the action tracker. Copying a row is manual. Updating one file does not update the others.
• It will not accept a JSON backup. JSON import exists only on the three browser tools, and only for a file of that tool’s kind.
• It will not store passwords, tokens, or access keys safely. Do not put them in Description or Response. Point to the organisation’s access process instead.

The rows below are fictional.

At the next review, if the sandbox is back but the six cases have not passed, leave I-01 open and rewrite Response. Do not call the launch safe in the status report while this row is open. Close R-02 only if training no longer depends on those tests.