What should an SME record in the first incident timeline?

Open one incident record early

The first hour of a possible security incident is usually untidy. A staff member notices an unexpected sign-in, another sees a failed integration, and a customer reports a strange email. Those observations may be related, or they may be coincidental. Open one incident record with a provisional identifier and owner before the team begins debating a final cause. Record who reported each item, when it was observed, which system it concerns and where the original evidence can be found. Label the report as an observation, not a confirmed breach. NIST's current incident response publication frames preparation, detection, response and recovery as connected risk-management activities; a usable timeline helps carry facts between them.

Keep the first record simple enough that a busy employee will use it. For every entry, capture an event time if known, the time the team learned of it, source, short description, confidence or status, and the next action or owner. A customer message received at 10:20 may describe an email seen at 09:50; these are two different clocks. An application log may show yet another timestamp. Do not silently sort them into a perfect story. Write 'reported time' and 'observed in log' separately until verified. This discipline prevents an early guess from becoming the unquestioned basis for containment, customer communication or later review.

Normalize clocks without erasing originals

Record the original timestamp exactly as the source presents it, including time zone or stated offset. Add a normalized working time in one agreed zone, such as Hong Kong time, only after the source zone is known. If the source zone is unknown, mark it unknown; do not assume the laptop, cloud service and staff phone all used the same setting. Note clock drift if it is discovered later. NIST's log-management guidance stresses that log analysis depends on adequate time information and synchronized clocks. A timeline that pretends every timestamp is comparable can put a response action before the event that prompted it and mislead the team.

For example, a hosted service records an alert in UTC while the help desk writes in Hong Kong time. The editor of the timeline should retain both original strings and calculate the comparable time with a documented conversion. If the alert source later turns out to have a five-minute drift, add a correction note that explains the basis; do not rewrite the original log excerpt. This worked example has no claimed real incident or measured response speed. The important lesson is traceability: another colleague should be able to reproduce why two entries were considered concurrent, sequential or unrelated, and to revise that interpretation when better evidence arrives.

Preserve what each source can actually prove

A login log may show that a credential was accepted; it does not, by itself, identify the human at the keyboard. A customer screenshot may show what appeared on one device, but not every recipient who saw the same message. A monitoring alert may establish that a rule fired, not that data was exported. State the narrow proposition each item supports and the unresolved alternatives. Link to the original entry or a controlled copy, including source system and collection time. Avoid pasting entire personal-data records into a wide incident chat merely for convenience. The timeline should help locate evidence and decisions without becoming an uncontrolled duplicate of sensitive data.

Prioritize short-lived material. Some logs rotate, dashboards overwrite views, and staff devices move on. The incident owner should ask which source may disappear soon and arrange an authorized export or preservation step before routine cleanup destroys it. Record who collected the copy, how it was made, where it is stored and any integrity check used. Do not claim a forensic chain of custody merely because someone saved a screenshot. Where formal investigation or legal proceedings may follow, involve the appropriate specialist and follow the organization's evidence-handling policy. NIST's incident guidance is general; it does not turn a small business note into court-ready proof by itself.

Record response actions beside observations

The timeline must include what responders did, not only what systems reported. Record the decision maker, reason and actual time for actions such as disabling an account, revoking a token, isolating a device, changing a rule or restoring a service. An action can change the evidence it is meant to protect: restarting a server may clear volatile information, while leaving it online may prolong harm. The right decision depends on the incident and available expertise. A concise note of the alternatives considered is more useful than a later statement that the team 'followed procedure' without explaining what was seen and why the action was selected.

Use separate status values for proposed, authorized, started and completed actions. A message saying 'we should revoke the key' is not proof it was revoked. After an action, verify its result in the relevant system and add that observation as another entry. If the verification fails, leave the action open and assign a next step. This is particularly useful when several people work across shifts: the next person can see whether an account was actually disabled or only requested. It also prevents the post-incident report from presenting an intention as a completed control. Keep internal operational details in an access-controlled record, while any customer-facing update uses a separate approved summary.

Revise the timeline with visible corrections

A first timeline is provisional. Assign an owner to revisit each uncertain entry as new logs, provider reports or staff recollections arrive. Preserve the original statement and append a correction or superseding assessment with the new source and time. A corrected event time should not make the earlier report disappear. Keep a short list of open questions: which accounts were affected, whether a suspicious action succeeded, when access ended, and what evidence is still missing. Record why a question is closed, not simply that it is closed. This makes the final review a traceable reconstruction rather than a polished narrative assembled from memory.

The closing review should compare the initial picture with what the team eventually verified. Identify which data source proved decisive, which was missing, and whether the response itself made later reconstruction harder. Update logging, retention or response playbooks only where the evidence shows a real gap. NIST's revision 3 recommendations support improving incident capability over time, but they do not prescribe one universal template for every business. The immediate deliverable for a small team is more modest: a record that distinguishes fact from inference, preserves the original trail and lets the next responder make a safer decision. If uncertainty remains, state it plainly in the final account.

Rehearse with a small scenario

Before an incident, test the template with a short tabletop scenario. Imagine that a staff member reports an unfamiliar administrator sign-in, a log entry seems to support it, and the cloud provider's dashboard is delayed. Ask one person to enter observations, another to identify evidence at risk of rotation, and the decision owner to record whether access should be suspended. Then introduce a correction: the log used UTC, while the report was written in Hong Kong time. The team should update its working chronology without deleting either original timestamp. This exercise reveals whether people know where logs live, who can export them and how a handover is made. It does not prove readiness for every attack; it tests whether the first record can support a reasoned next step.

At the handover, ask the incoming responder to state what is established, what is inferred and what still requires a check. If that person cannot find the original alert, verify whether a key was actually revoked, or identify the source time zone, the timeline needs improvement. Give the record a restricted location and a named owner, with access for those genuinely involved in response. Decide later how long it should be kept under the business's obligations and policies; do not turn a convenient incident folder into permanent unrestricted storage. Where personal data or a regulated system may be involved, seek the relevant specialist assessment before drawing notification or legal conclusions. A good early timeline supports those decisions; it cannot replace them.

Use a separate decision log when the incident becomes complex, but keep it linked to the same timeline identifier. The decision log can hold who authorized a disruptive step, the alternatives considered and the review point for reversing it. The timeline then records when the action actually happened and what verification showed. This prevents a long narrative from burying an operational commitment. It also helps when a supplier or specialist joins later: they can read the current facts, open questions and authorized actions without being given every unrelated customer record. At each shift change, state which evidence may expire before the next review and who will preserve it. A handover that only says 'investigation ongoing' leaves the most time-sensitive work to chance.