Template

Incident Timeline Notes

The Incident Timeline Notes template helps an organization record a neutral timeline during an outage, disruption, mistake, access issue, vendor problem, service interruption, or other operational incident.

Small organizations often try to reconstruct what happened after the fact. By then, times may be unclear, decisions may be forgotten, messages may be scattered, and important details may be mixed with assumptions.

This template provides a simple way to record what was noticed, when it was noticed, what changed, who was involved, what actions were taken, and what still needs follow-up.

The goal is clarity, not blame.

Purpose

The purpose of this template is to help an organization document:

• what happened
• when it happened
• who noticed it
• what service, vendor, account, or record was involved
• what actions were taken
• what was communicated
• what decisions were made
• what changed
• what remains unknown
• what follow-up is needed

The template is meant to preserve useful context while the situation is still fresh.

Who this template is for

This template is designed for:

• small businesses
• nonprofits
• founder-led organizations
• community projects
• small teams
• independent maintainers
• early-stage organizations
• organizations without formal incident-response staff

Larger organizations may adapt it, but they may need formal incident-response, legal, security, insurance, HR, regulatory, or compliance processes.

Important boundary

This template is not:

• legal advice
• cybersecurity advice
• compliance advice
• forensic analysis
• insurance advice
• HR advice
• regulatory advice
• a formal incident-response plan
• a substitute for professional support
• a public statement
• a complete investigation by itself

Some incidents may require qualified legal, cybersecurity, insurance, accounting, HR, regulatory, or law-enforcement guidance.

This template is only a practical note-taking structure.

Recommended use

Use this template when something operationally confusing or disruptive happens.

Examples include:

• website outage
• email outage
• payment issue
• vendor service interruption
• domain or DNS issue
• account lockout
• billing or renewal problem
• support inbox issue
• customer report
• mistaken configuration change
• missing record
• access ownership confusion
• contractor or vendor communication issue
• service cancellation problem
• suspected unauthorized activity

Start the timeline early. It is easier to record events as they happen than to reconstruct them later.

Template fields

The Incident Timeline Notes template may include the following fields.

Date

Record the date of the entry.

Example:

• 2026-07-08

Time

Record the time of the event, observation, action, communication, or decision.

Examples:

• 9:15 AM
• Around 2:30 PM
• Before opening
• After customer email
• Exact time unknown

If exact time is unknown, say so.

Time zone

Record the time zone if relevant.

Examples:

• Eastern Time
• UTC
• Local office time
• Vendor dashboard time

Time zones are especially important when reviewing logs, vendor notices, emails, support tickets, or international activity.

Entry type

Record what kind of timeline entry this is.

Suggested values:

• Observation
• Action
• Decision
• Communication
• Vendor update
• Customer report
• Internal note
• Follow-up item
• Resolution note
• Review note

Entry types make the timeline easier to scan later.

Summary

Write a short, factual summary.

Examples:

• Website returned an error page.
• Customer reported checkout failure.
• Vendor status page showed degraded service.
• Password reset email was not received.
• Support ticket opened with vendor.
• Service restored after DNS change.

Keep the summary neutral.

Details

Record relevant details.

Examples:

• Error message observed.
• Service affected.
• Vendor involved.
• What was checked.
• What was changed.
• Who was notified.
• What response was received.
• What remains unclear.

Avoid unnecessary sensitive information.

Source

Record where the information came from.

Examples:

• Customer email
• Internal observation
• Vendor status page
• Support ticket
• Admin dashboard
• Team message
• Phone call
• System alert
• Invoice notice
• Website test
• Public notice

The source helps later review.

Person or role

Record who added the note, made the observation, took the action, or handled the communication.

Examples:

• Founder
• Operations lead
• Website maintainer
• Finance owner
• Customer support
• External provider
• Vendor support

This field is not for blame. It helps establish context.

Related vendor or service

Record the vendor, service, platform, account, or system involved.

Examples:

• Website host
• Domain registrar
• DNS provider
• Payment processor
• Email provider
• Accounting platform
• Cloud storage
• Support inbox

This can connect the incident timeline to the vendor inventory.

Related record

Record any related documentation.

Examples:

• Vendor and Service Inventory
• Access Reference Register
• Responsibility Record
• Continuity Notes
• Support ticket
• Review Log
• Change Log

Use safe references only.

Action taken

Record what action was taken, if any.

Examples:

• Checked vendor status page.
• Opened support ticket.
• Confirmed billing status.
• Restarted service.
• Reverted change.
• Notified customers.
• Updated access reference.
• Added follow-up item.
• No action taken yet.

Result or status

Record the current result or status.

Suggested values:

• Open
• Monitoring
• Waiting for vendor
• Needs follow-up
• Escalated
• Resolved
• Closed
• Unknown

Follow-up needed

Record any follow-up items.

Examples:

• Review vendor ownership.
• Add backup owner.
• Update access reference.
• Review renewal reminders.
• Add note to documentation review log.
• Confirm customer communication.
• Check logs again tomorrow.
• No follow-up needed.

Last updated

Record when the timeline entry was updated, if useful.

Minimum version

A small organization can begin with these fields:

This minimum version is enough to preserve useful context.

Example timeline

Neutral language

Use neutral language where possible.

Prefer:

• Customer reported checkout error.
• Payment processor dashboard showed pending status.
• Domain renewal status was unclear.
• Support ticket opened with vendor.
• Access owner not immediately known.
• Vendor status page showed degraded service.

Avoid:

• Someone broke checkout.
• The vendor failed us.
• This was careless.
• No one knew anything.
• This was definitely caused by a specific person.

Neutral language makes the record more useful and less defensive.

Facts, assumptions, and unknowns

It is useful to separate facts from assumptions.

Fact

A fact is something directly observed or confirmed.

Example:

Vendor status page showed degraded service at 9:25 AM ET.

Assumption

An assumption is a possible explanation that has not been confirmed.

Example:

Possible connection to vendor outage. Not confirmed.

Unknown

An unknown is something the organization does not yet know.

Example:

Unknown whether failed checkout affected all customers or only one customer.

Clearly marking assumptions and unknowns helps prevent the timeline from becoming misleading.

Sensitive information

Incident timelines can accidentally collect sensitive information.

Do not include:

• passwords
• API keys
• MFA recovery codes
• private keys
• seed phrases
• payment card numbers
• customer personal data
• confidential customer messages
• private employee information
• regulated data
• sensitive screenshots
• legal advice
• confidential vendor contracts
• unnecessary security details

If sensitive evidence must be preserved, store it in an approved secure location and reference it safely.

Example:

Screenshot saved in approved incident evidence folder. Do not attach to general timeline.

When to update this template

Update or use the Incident Timeline Notes template when:

• a service becomes unavailable
• a vendor issue affects operations
• access to an account is unclear or lost
• a billing or renewal issue appears
• a customer reports a recurring problem
• a key record is missing or outdated
• a mistaken change affects operations
• a process failure creates confusion
• an issue requires follow-up
• a decision is made during a disruption
• communication is sent about the incident

Closing the timeline

An incident timeline can be closed when:

• the issue is resolved
• no further action is needed
• follow-up items are recorded elsewhere
• ownership has been assigned
• the organization understands enough to move forward
• a review has been completed, if needed

Closing a timeline does not mean everything went perfectly. It means the active note-taking period is complete.

Post-incident review

After an incident, review:

• what happened
• whether records were clear
• whether vendor ownership was known
• whether access references were current
• whether responsibility records were accurate
• whether continuity notes helped
• what should be updated
• what can be simplified
• what should be reviewed before the next incident

A post-incident review should focus on learning and improvement.

Related standard

This template supports the Incident Timeline standard.

It also connects to:

• Vendor Inventory
• Access References
• Responsibility Records
• Continuity Notes
• Review Routines

License

This template is intended to be provided as a free public resource.

Unless otherwise stated on the project license page, the standards and templates are made available for use, adaptation, and sharing under the project’s open content license.

The project name, logo, and official identity are not included in the template license.

Status: Draft · Version: 0.1 · Last updated: 7/8/2026