Four categories, not one
A risk might happen. An issue already has. Logging the second as the first keeps a real problem looking hypothetical — which is the most common way a RAID log misleads.
Risks, assumptions, issues and dependencies
Four categories that are not interchangeable. Logging an issue as a risk keeps a real problem looking hypothetical.
The log
Needs attention
The four categories
Risk — might happen. Has a probability and an impact, and gets mitigated.
Assumption — believed true and not verified. Becomes an issue the moment it turns out to be wrong, which is why assumptions get verified rather than managed.
Issue — has happened. Needs a response now, not a mitigation.
Dependency — something outside your control that the plan needs. Managed by relationship and early warning rather than by action.
The categories are not decoration
The most common failure is logging issues as risks. It is comfortable — a risk has a mitigation and a future tense, an issue demands a response today — and it means a project can report a manageable risk register while several things have already gone wrong.
If every open item on a live project is a risk and none is an issue, that is worth looking at directly.
Assumptions are the quiet ones
An assumption sits in the log looking harmless for months and then becomes the reason the project is late. They do not get managed; they get verified, and the useful question at every review is which assumption could now be checked cheaply.
A date is what makes it close
Open items without dates accumulate. An issue with no date on it is not being worked on, it is being carried, and the log slowly turns into a record of things everyone has stopped reading.