Risk Register

Phase: Planning | Audience: Internal | Project: WEB-2026-01 Corporate Website Development

Understand it first

In simple words: The Risk Register lists things that might go wrong, how likely and how serious they are, what we will do about them, who owns them and how much money is kept aside.

Think of it like: Before an outdoor wedding you note: 'rain is possible, so book a tent'. The risk is rain; the response is the tent; the cost of the tent is your reserve.

When is it created?	Planning, reviewed every Monday
Who prepares it?	Project Manager with risk owners
Who approves or uses it?	Internal; top risks reported to sponsor
What happens next?	Risks that happen move to the Issue Log

How it connects to other documents

Reserves add up to the ₹45,800 contingency in the Budget.
Risks R1 and R3 later became issues I-03 and I-02 in the Issue Log.
Top risks appear in the Weekly Status Report.

The sample document

Below is the actual document for project WEB-2026-01. Read the purpose first, then go through each numbered section.

Issued by: [Your Company] Technologies Pvt. Ltd.

Purpose: Identified risks with probability, impact, response and owner. Reviewed every Monday. Scores use a 1–5 scale; score = probability × impact.

Item	Detail
Document no.	WEB-2026-01/RR
Version	1.3
Date	30 Oct 2026
Owner	Project Manager
Audience	Internal
Phase	Planning

1. Register

ID	Risk (cause → effect)	P	I	Score	Response	Action	Owner	Reserve (₹)	Status
R1	Client requests a third design round → design effort and schedule overrun	3	3	9	Mitigate	Show designs to MD before sign-off; bill extra rounds via rate card	Designer	14,000	Open
R2	CMS or form integration problems → extra backend effort	2	4	8	Mitigate	Build and test form in week 4 on staging	Backend	12,750	Open
R3	Client content arrives late → developers idle, launch at risk	4	3	12	Mitigate	Content calendar; weekly reminder; use placeholder text to keep building	PM	11,000	Open
R4	Licence or hosting prices rise → higher non-labour cost	2	2	4	Accept	Buy annual licences at start	PM	8,050	Closed
R5	Diwali week reduces capacity → schedule slip	3	2	6	Avoid	Plan 60% capacity in week 6	PM	0	Monitoring
R6	Key developer unavailable → development delay	2	4	8	Mitigate	Code in Git; backup developer identified	Delivery Head	0	Open
R7	Client pays late → cash gap in month 2	3	3	9	Mitigate	Invoice on sign-off day; payment terms in SOW	PM	0	Open
R8	Informal requests via chat → scope creep	4	3	12	Avoid	All requests through change request form	PM	0	Open
R9	Delayed DNS or domain access → go-live delay	3	3	9	Mitigate	Access requested in week 1; test DNS change in week 9	Backend	0	Open
R10	Performance target missed → quality criterion fails	2	3	6	Mitigate	Image compression and caching from the start	Frontend	0	Open
	Total contingency reserve							45,800

2. Scoring guide

Score	Rating	Action
12–25	High	Weekly action; report to sponsor
6–11	Amber	Monitor weekly; response plan ready
1–5	Green	Review monthly

Note: Update on 30 Oct: R1 partly happened (home design needed extra rework, logged as issue I-03). R4 closed after licences were bought at the quoted price.

WEB-2026-01/RR · v1.3 · Internal. Bracketed items such as [Client Name] are placeholders.

Key takeaways

Score = probability × impact; focus on the highest scores.
Write risks as cause → effect.
Every risk needs an owner and an action, not just a description.

Common mistakes to avoid

Writing vague risks like 'project may be delayed'.
Creating the register once and never reviewing it.
No money set aside for likely risks.

Next lesson: 21. Quality and Test Plan