In every acquisition from a running device the DEFR: first considers capturing what would be lost at power-off (RAM, running processes, network connections, date and time settings), and a live acquisition where non-volatile data must be taken from a running device, on the console or remotely over the network, each with its own tool set; never trusts programs on the system, preferring trusted tools brought by the DEFR (static binaries), is competent with validated tools and can account for their effect on the system (evidence displaced, memory paged out when software loads), and records all actions and resulting changes, including when the effect of introducing a tool cannot be determined; places captured volatile data in a logical file container where possible, or else an archive such as a ZIP file, hashes it and records the value, storing containers on a medium prepared (formatted) for the purpose; and images live non-volatile storage with a validated imaging tool onto a prepared medium, new or sanitised, making sure an image held in a file container cannot be corrupted. Where a device is locked, direct memory access through another interface (FireWire, for example) may be used.
This control maps to 3 controls across 2 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 3 it maps to, and the evidence behind each claim, over MCP and REST.