Where local policy or law does not set the content, a report should include at least: the author's qualifications or competence for the investigation and the report; the information given to the team before starting, including the kind of report expected; the nature of the incident; its time and duration; its location; the investigation's objective; the team members with their roles and actions; the investigation's time and duration; its location; the factual details of digital evidence found; damage seen to the evidence during the work and how it affected later steps; the limits of the analysis (incomplete data, operational or time pressure); and the processes used, with tools where relevant. It may also give an interpretation (with all plausible interpretations and their relative likelihoods, as opinion if necessary), conclusions and recommendations for more investigation or for remediation. Opinions are clearly separated from facts and justified. Report design can be done during the readiness and initialization classes of ISO/IEC 27043, and a template design process can be validated with the ISO/IEC 27041 framework.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.