NIST SP 800-61
Handling an Incident
2.5. Incident Documentation
An incident response team that suspects that an incident has occurred should immediately start recording all facts regarding the incident. A logbook is an effective and simple medium for this, but laptops, audio recorders, and digital cameras can also serve this purpose. Documenting system events, conversations, and observed changes in files can lead to a more efficient, more systematic, and less errorprone handling of the problem. Every step taken from the time the incident was detected to its final resolution should be documented and timestamped. Every document regarding the incident should be dated and signed by the incident handler. Information of this nature can also be used as evidence in a court of law if legal prosecution is pursued. Whenever possible, handlers should work in teams of at least two: one person can record and log events while the other person performs the technical tasks. Section 3.3.2 presents more information about evidence.
The incident response team should maintain records about the status of incidents, along with other
pertinent information. Using an application or a database, such as an issue tracking system, helps ensure
that incidents are handled and resolved in a timely manner. The issue tracking system should contain
information on the following:
The current status of the incident (new, in progress, forwarded for investigation, resolved, etc.)
- A summary of the incident
- Indicators related to the incident
- Other incidents related to this incident
- Actions taken by all incident handlers on this incident
- Chain of custody, if applicable
- Impact assessments related to the incident
- Contact information for other involved parties (e.g., system owners, system administrators)
- A list of evidence gathered during the incident investigation
- Comments from incident handlers
- Next steps to be taken (e.g., rebuild the host, upgrade an application).
The incident response team should safeguard incident data and restrict access to it because it often
contains sensitive information – for example, data on exploited vulnerabilities, recent security breaches,
and users that may have performed inappropriate actions. For example, only authorized personnel should
have access to the incident database. Incident communications (e.g., emails) and documents should be
encrypted or otherwise protected so that only authorized personnel can read them.