The paper trail is the deliverable in a compromise recovery

Recovery after a domain compromise is judged by whether the organisation can show what it did and why. The technical work is bounded: rebuild the systems that were touched, rotate the credentials that were exposed, and restore service. The evidence that the work happened correctly is what decides whether the incident closes or returns.

Two audiences, two different questions

The security team needs to know what the attacker could reach. The audit committee and, in a regulated sector, the supervisor need to know when the organisation knew, what it decided, and who approved the decision.
Those questions are answered by different documents. The technical timeline records detection, containment and eradication. The decision log records who authorised taking a service offline, whether a ransom demand was answered, and on whose authority an executive account was reset outside the normal change process. Both are needed, and neither substitutes for the other.

The routine that produces the record

Evidence capture should precede remediation wherever the two compete. Volatile data, including running processes, network connections and the contents of memory, disappears at the first reboot. The order is capture, then rebuild, then verify, and the temptation to reboot a suspected host to clear a problem is the most common way the record is lost.
The timeline should be captured while the incident is live rather than reconstructed afterwards. A person assigned to keep it has a durable advantage over a team that intends to write it up later, because the decisions that matter are made under time pressure and are rarely memorable a week later.
Chain of custody matters for anything that may support a legal or insurance process. Recording who handled an image, and when, is cheap during the incident and expensive to establish later.

What verification looks like

Recovery is a hypothesis until it is tested. Three tests belong in the plan.
Restore test. A backup that has not been restored is an assumption. The test should restore to an isolated environment and confirm the data is usable, not merely that the backup job reported success.
Credential test. Every credential that was present on a compromised system should be treated as exposed. The test is whether authentication with the old secret fails after rotation. A rotation that leaves a service account valid is a rotation that has not happened.
Detection test. The controls that are meant to catch a return visit should be exercised deliberately, by attempting the technique in a controlled setting and confirming the alert fires.

The decisions that need a name attached

Three decisions are usually undocumented in a compromise recovery and are usually the ones an auditor asks about.
The scope decision: which systems were treated as in scope for rebuild, and what evidence justified that boundary. A boundary drawn too tightly leaves a foothold in place.
The communication decision: what was disclosed to customers, regulators and staff, when, and by whom. Where a reporting obligation exists, the clock usually starts at the moment of awareness rather than the moment of confirmation.
The exception decision: which controls were relaxed to restore service, and when they will be restored. Emergency changes that are never reverted are how a temporary bypass becomes a permanent one.

A record that survives review

A recovery record that survives external review tends to have three properties. It is contemporaneous, written as events happened rather than after the fact. It is attributable, with a name against each significant decision. It is testable, referring to evidence that can be produced on request.
None of those properties require a tool. They require that someone owns the record from the first hour, and that the organisation treats it as an output of the recovery rather than paperwork generated by it.

References

[1] NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide. https://csrc.nist.gov/pubs/sp/800/61/r2/final
[2] CISA, Incident and Vulnerability Response Playbooks. https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks
[3] NIST SP 800-184, Guide for Cybersecurity Event Recovery. https://csrc.nist.gov/pubs/sp/800/184/final