- When the risk can no longer happen (maybe it already has occurred, or maybe it can no longer occur.)
- When the project has closed and there are still open risks.
Typically this second class of risks will be to do with the business operating the new product, system or process. For example, if you release a new CRM there is always a risk of critical system failure which was not there before.
But that is not always the case. Many projects launch their product with some planned or unplanned cleanup work to follow; for example some product documentation will need to be done, or a support process for a particular exception will need to be developed.
Regardless of the type of risk, at the end of the project risks need to be handed over to the responsible operations managers, and it should not come as a surprise to them. If you have managed your risks well through the project process you have informed them of the risks and management plans as you have gone along, and all the better of they have been involved in the identification and management of your project risks.
I am an advocate of a risk handover meeting where you produce all the risks from your projects risk management system and talk your stakeholders through them so that they get a complete and appropriate understanding of the risks they are taking on. You may also be able to hand over some of your project's subject matter expertise in the form of advice on how to handle certain operational risks.
Organisations with high process maturity or an interest in continual improvement often migrate project risk registers into larger databases so that future projects can learn from previous experience. For example, if you have had a resource risk on your project (because the labour market is tight or because the company runs to many projects for the number of people) the organisation can learn if you were a one off circumstance or if there is a systematic problem that needs addressing.