Risk Register template
What is a Risk?
You can think of a risk as a project issue that has not come true yet. The risk could be an opportunity, but more likely it is something that would have a negative impact on the project outcome if it were to eventuate. Good risk management is one of the keys to a successful project - if you identify early on the things that might go wrong, you can take steps to reduce their impact or avoid them altogether.

Suggested Use and Tips
Make a copy of the table below to record risks identified during the Risk Identification Workshop at the beginning of the project. Ensure every significant risk has an owner and a mitigation plan. Risk scores of 12 and above can be considered significant. As the project progresses, add new risks that are uncovered and close any that have been mitigated.
Assumptions made during planning may be a source of risk. Maintain the Risk Register regularly during the project.
Create a "Top 5" risk list from the Risk Register and share it with the team and other stakeholders each week. (The Risk Register itself will soon become too big for your stakeholders to digest).
Use the Risk Register as an input for your and the team's actions each week.
Ensure the project team knows how to raise and escalate risks, and what the mitigation plans are for key risks. Schedule the riskiest work early in the project so you have more time to take corrective actions.
Escalate the risks you can't solve to get assistance, or at the very least acceptance of the risk by the project sponsor and key stakeholders.
The goal is fewer unknowns and being prepared for corrective action - not elimination of all project risk. See bottom of this page for example risk categories.

Risk Register

Category	Risk	Probability (1-5)	Impact (1-5)	Total Risk Score (=PxI)	Mitigation Strategy	Owner	Status	Comments	
									
Team	e.g. The
project team	4	5	20	Responsibilit
ies have	John		OPEN	15
de	/6/13: 3
veloper	
									
	is not				been			candidates	
	adequately				defined on			are in the	
	staffed,				the project			pipeline	
	and/or				home page				
	responsibiliti				and shared				
	es are				with the				
	unclear.				team and				
					other				
					stakeholders				
					. Team				
					Leads need				
					to spend				
					additional				
					time on				
					recruiting				
					and HR				
					team need				
					to start a				
					hiring				
					campaign.				
									
Communica	Project	4	3	12	Weekly	Lisa		STABLE		
tions	sub-teams				forum is now					
									
	are not				in place for				
	communicati				Team A and				
	ng				Team B				
	frequently or				leads.				
	deeply								
	enough								

										
Technical	We	4	5	20	Prototype	Suren		WATCH		
	encounter				review with					
									
	significant				product				
	technical				owner in first				
	and				week of				
	operational				July. Senior				
	roadblocks				Architect is				
	with product				investigating				
	performance				alternate				
	and				technical				
	reliability				solutions in				
					June.				

Example Categories
General
Business-level risks: globalisation & internationalisation, technology changes, changes in competition, changes in demand for the products & services, ownership changes (mergers & acquisitions), rapid expansion or contraction of the products & services.
Project-level risks: resource availability, communication frequency and style, implementation risks, technology risks, changing stakeholders, supportability considerations.

Specific
Strategic risks: will this project bring us the best return on investment of resources?; what is the impact to the company if this project fails?
Management risks: have all the stakeholders agreed on project goals and priority?; have success metrics for the project been defined, and are they measurable?
Legal risks: any potential legal issues?, e.g. patent infringement, licensing considerations, open-source plans
Team risks: do we have the right skills & availability in-house?; is solid management in place for any 3rd parties?; is the team co-located or distributed?
Technical risks: making the right technology choices, adding enough buffer for learning new technologies & dealing with any unexpected shortcomings; compatibility with existing solutions; designing for scalabilty/performance/security
Integration risks: are there inter-dependencies on other projects?; are these clearly understood by all affected teams?; has enough end-to-end integration time been scheduled?
Quality risks: does the team have a plan for writing unit, functional & automated tests?; is there a dogfooding plan in place?; have we identified customers for the beta program?; are QA engineers available?; has enough QA time been scheduled?
Planning risks: any big assumptions that could turn out to be incorrect? Open questions that need to be resolved? Big decisions that haven't yet been made?