Accurate action logging is the foundation of a defensible incident response. Every action taken during an incident — from isolating a host to notifying a regulator — should be recorded in the incident timeline. This documentation serves as evidence for regulators, supports post-incident learning, and protects your organisation legally.

Action Entry Fields

When logging an action, the following fields are available:

Description(required) — A clear, factual account of the action taken. Be specific about what was done, to which system or account, and the outcome. Avoid vague entries. Instead of “Checked email”, write “Reviewed email headers for message ID abc123 and confirmed spoofed sender domain”.
Timestamp(required) — When the action was performed. Defaults to the current date and time. Can be set to a past time if you are recording an action after the fact (see backdating below).
Performed by(required) — The person who carried out the action. Defaults to the logged-in user. Can be changed to any team member associated with the incident if you are logging on someone else's behalf.
Category(optional) — A classification for the action type, such as Technical, Communication, Legal, or Management. This helps with filtering and reporting.
Evidence(optional) — Attach files, screenshots, or log excerpts to support the action record. See evidence attachments.
Key decision(optional flag) — Mark the action as a key decision if it represents a significant judgement call. Key decisions are highlighted in the timeline and surfaced in reports.

Backdating Actions

In the heat of an incident, it is not always possible to log every action as it happens. CrownSync allows you to backdate action entries by changing the timestamp to reflect when the action actually occurred rather than when it was logged.

When you backdate an entry:

The entry is inserted into its correct chronological position in the timeline
A small indicator notes that the entry was logged after the fact, showing both the action time and the logging time
The audit log records the actual logging time alongside the stated action time

Backdating is expected and normal during incident response. Regulators understand that real-time logging is not always feasible. However, you should aim to log actions as close to real time as possible, and backdate only when necessary.

Log brief notes in real time

Even a one-line entry logged in real time is more valuable than a detailed entry written hours later. During the active response, use brief descriptions to capture the essence of each action. You can always expand the detail later by editing the entry.

The “Performed By” Field

The “Performed by” field records who actually carried out the action. This is important because:

It creates an accurate record of who did what during the response
It supports accountability and post-incident review discussions
It may be required by regulators or insurers as part of breach documentation

Any team member with access to the incident can log actions, including on behalf of others. The system records both the person who performed the action and the person who logged the entry, maintaining a complete audit trail.

The Key Decision Flag

Certain actions during an incident represent pivotal decisions that materially affected the course of the response. Flagging these as key decisions serves several purposes:

They are visually highlighted in the timeline with a distinct badge
They appear in a dedicated section of incident reports
They are automatically included in post-incident review agendas
They help regulators understand the reasoning behind your response approach

Not every action is a key decision. Reserve this flag for moments where a judgement call was made that could have gone differently — choosing to isolate versus monitor, deciding when to notify, or authorising external assistance.

Editing Logged Actions

After an action is logged, it can be edited to correct typos, add detail, or attach additional evidence. However, edits are tracked:

The original entry content is preserved in the audit trail
An “edited” indicator appears on the timeline entry
The edit history shows what changed, who changed it, and when

Actions cannot be deleted from the timeline. This immutability is by design — it ensures the integrity of the incident record for compliance and legal purposes.

Timeline entries are immutable

Once logged, actions cannot be removed from the timeline. You can edit the content of an entry, but the original version and all subsequent edits are retained permanently. This protects the evidential value of the incident record.