Application craft
How to write a grant risk register assessors can trust
Build a practical risk register for your UK innovation grant application, with clear scoring, named owners, useful mitigations and evidence assessors can test.
Start with the decisions your risk register must support
A grant project risk register should explain what could stop your project delivering, how you will spot trouble and what you will do about it. For a founder or technical lead, the starting question is simple: which assumptions could break our technical approach, delivery plan or commercial case? Answer that before choosing a template. A list of generic risks such as delays, competition and recruitment will tell an assessor little about your actual project.
Read the competition guidance first. Check whether risks belong in an application answer, a prescribed appendix or another supporting document, and follow any format restrictions. Assessors work against the published questions and criteria, so make the register support those requirements rather than act as a separate management exercise. Where delivery risk is assessed, the useful evidence is that you understand the project's uncertainties, have proportionate controls and can make sensible decisions if those controls fail.
Turn uncertain assumptions into specific risk statements
Bring together the people responsible for technology, delivery, finance and commercialisation. Ask each person which project assumption they are least comfortable defending. Cover technical performance, access to equipment or data, recruitment, suppliers, regulatory requirements and customer adoption where relevant. Separate risks from existing problems: equipment that might become unavailable is a risk; equipment you already know you cannot access is a problem requiring a change to the plan. Do not hide a known constraint behind uncertain wording.
Write each risk as a cause, an uncertain event and a consequence. For example: because the prototype has only been tested under controlled conditions, performance may deteriorate in the intended operating environment, preventing the planned demonstration from meeting its acceptance criteria. This is more useful than writing 'technical failure'. It identifies an assumption that needs testing and explains what is at stake. Keep distinct risks separate when they have different owners, warning signs or responses.
Score consistently and explain the judgement
Unless the competition specifies a method, choose a simple likelihood and impact scale that your team can apply consistently. Define the categories in words before scoring anything. Likelihood should reflect how plausible the event is during this project, while impact should reflect consequences for delivery, cost, technical outcomes or exploitation. Explain significant ratings using available evidence, such as test results, supplier confirmations or recruitment experience. A colour or numerical score alone does not explain your judgement.
Record the current exposure and the expected exposure after any proposed mitigation, making clear which controls are already in place. Avoid downgrading every risk to low simply because you have written an action beside it. A planned test can reveal whether a technical problem exists without reducing the probability of that problem. Show what remains uncertain and whether the project could still proceed. If a risk could make the project unviable, explain the decision it would trigger.
Give each major risk an owner, trigger and response
A usable register needs a risk identifier, a specific statement, likelihood and impact, an accountable owner, mitigation, a warning trigger and a contingency. Add the status and next review point so the document can guide delivery. Assign ownership to someone with authority to act, not simply 'the team'. For partner dependencies, distinguish the person carrying out an action from the person accountable for monitoring its effect on your project. Confirm these responsibilities with the people involved.
Make mitigation concrete. For the prototype example, an early test under representative conditions could expose performance limits before the design is fixed. The trigger might be failure against a defined acceptance criterion; the response might be a design review and a decision between alternative technical approaches. Explain any implications for scope, resources and delivery. 'Monitor closely' is not sufficient on its own, and 'use another supplier' is not credible unless you have checked that a suitable alternative exists.
Check the register against your application and budget
Cross-check every major response against the rest of the application. If you promise additional testing, show where the work and resources sit. If a fallback depends on specialist equipment, establish whether it is available. Do not assume that a generic contingency budget is eligible: check the competition's cost rules and explain allowable activities through the required budget format. Similarly, a proposed scope change may require funder approval. Your register should acknowledge constraints rather than promise freedoms you may not have.
Common mistakes include copying a previous project's risks, treating every risk as equally important and claiming that experienced staff eliminate uncertainty. Another is confusing research uncertainty with poor preparation. A technical challenge can be a legitimate reason for undertaking R&D, but an unresolved access permission or unsupported supplier assumption needs practical attention. Ask a colleague outside the writing team to challenge the register: can they see what could go wrong, what evidence supports your judgement and who would act?
Where to go next
Before submitting, run a short review with the proposed risk owners. Confirm that the most consequential assumptions are covered, the actions are realistic and the application tells a consistent story. Check that you have not introduced extra activities without accounting for their resource needs. Keep the working register after submission and update it as evidence changes. If funded, use it alongside the funder's reporting and change-control requirements, rather than treating it as a document written only to win an award.
If you are unsure whether your risks strengthen the case for an innovation project or expose gaps that need resolving first, book a free eligibility call with GrantUp. Bring the competition guidance, a short project summary and your main technical and delivery uncertainties. The discussion can help establish whether the opportunity fits your project and which questions need attention before you commit to an application. A risk register cannot guarantee funding, but it should make your delivery case easier to evaluate.
Ready to turn this into a funded proposal?
Book a free 30-minute consultation with a senior grant consultant. We will check your eligibility, match you to the right program, and map out your submission timeline.
Learn more about our approach