Issues are risks that have a 100% likelihood of occurrence which may or may not result in a change to improve the negative impact to a project. They may be forward looking like a risk register to identify and manage how the issues will be handled, or they may be rearward looking to identify patterns of problems based on historical data so that solutions to systemic problems may be found.
While issues are negative situations which may require a response, changes are the responses to some situation that typically involves altering the configuration of some project deliverable or artifact. They may also be forward looking or rearward looking. Changes often require significant overhead (business case, change board approval, schedule commitment, etc.) so multiple minor changes may be bundled together and implemented on the next planned version or blockpoint release to reduce unnecessary rework and overhead. A "next-change log" would collect those items so they are not forgotten, or it can be a prioritized backlog of incremental changes. A rearward looking change log is used for configuration management to record what changes were made at each iteration. If problems occur after a new product version release, the rearward looking change log can help identify what change caused the new problems. Saving Changes...
An issue log is used to track problems which are or could impact the project's objectives if not resolved. A change log is used to summarize key details about the formally managed changes in the project. A similar tool (e.g. MS Excel or SharePoint) could be used to manage both but the workflow and fields for a change will be quite different than those for an issue.
For simplity: Issue log is used to record a list of ongoing and closed issues including issues that may cause changes to a project. Change log is used to record changes made to a project. Saving Changes...
Few clarifications: issues are not risks but the materialisation of a risk. There is no such thing as 100% likelihood :).
Unlike risks issues have always a negative impact on a project. Issues can be identified in any phase of the project, not only during testing. For example, lack of support from the sponsor is always an issue, although it can be included in the issue register but it must be managed by the project manager.
There are few change registers in a project, each one with his own scope:
1) the change request register, documenting requests to change one of more parameters of the project: scope, budget or time-frame
2) change/decisions log that will contain all the decisions taken to alter the planed activities. For example changing priorities or project resources. Those decisions usually won't trigger a Change Request. The change log is an important instrument in identifying risk and issues as well as supporting change requests. The project change log/register is mainly
3) Technical change log to capture any change done to the production environment. This is managed by the CAB unlike the other 2 that are PMs responsibility Saving Changes...