I have been involved in multiple remediation activities over the years. Retrospectively creating Functional Specification is a good approach. It describes the user agreed functionality in a single document (both user requirements and functional design).
If the vendor is supporting the source code you should not need a Detailed Design spec for the structure of the code. If you are supporting the architecture of the application (e.g. wiring), you should have some elements of design documented(e.g. wiring diagrams or an a brief architecture spec in the Functional Specification).
You did not mention testing in your original email. If testing did occur before, you will need to ensure that that previous testing adequately tested key functional Specification elements (maybe through a Traceability Matrix). This could be a tool to address the risk assessment mentioned earlier.
If the system has been in operation for years and was tested, then you should confirm (via the TM) that the key functions were tested.
If the system was never tested, then you may want to do some high level testing of key functions. You should have a retrospective Validation Report, assuming none exists and assuming this is a regulated application. If the system was never tested, you should analyze the last couple years of incidents that have occurred in production and summarize (in the Validation Report) that the system has been operating in a stable mode (e.g. mainly password resets and normal production issues).
So, Functional Spec, Testing and Validation Report are key. A Traceability Matrix can be part of the package and can be used to document key functionality and how it was tested or why not tested.