Purpose

This article clarifies who is responsible for completing and updating the different fields in the digital platform during an ongoing incident.

The allocation of responsibilities may vary between organizations.
However, the key principles are:

Ownership is clear

• Roles and responsibilities are assigned
• Documentation is accurate and structured
• The platform is used consistently
• No single function becomes overloaded

This is not about who can write in a field —
it is about who owns the responsibility for ensuring that it is kept updated.

Important About Functional Titles

Below, examples of functional roles are used such as:

• Planning / Intelligence
• Liaison / Coordination
• Public Information / Communications

These are examples only.

The best Incident Management Team is the one designed to fit your organization and the specific incident.

Interpret the responsibility allocation below according to your own structure, terminology, and mandates.

What matters is not the title of the function — but that ownership is clear.

Core Principles

1. Content ownership and documentation responsibility may differ

The function or individual who owns the content is not always the one who documents it in the system.

Example:

• The Incident Commander owns the objective
• The Log-keeper documents the wording

It is therefore important to distinguish between:

• Content ownership (who owns the issue)
• Documentation responsibility (who writes in the platform)

2. The Log-keeper holds overall responsibility for structure and quality — in cooperation with the Incident Commander / Chief of Staff

The Log-keeper has overall responsibility for structure, quality, and coherence in the documentation.

This is done in close cooperation with the Incident Commander or Chief of Staff.

This means the Log-keeper ensures that:

• Decisions are clearly documented
• Objectives are traceable
• Actions are linked to decisions
• The incident timeline can be understood afterward
• The platform is used consistently and structurally

The Incident Commander supports this by:

• Clarifying role allocation
• Making structural decisions when needed
• Ensuring compliance with agreed structure

The Log-keeper owns the issue of documentation quality and structure, with the Incident Commander as support.

3. Only the current situation picture should remain visible

The guiding principle is that only current and relevant information should remain visible in:

• Facts
• Status

It is important to remember:

• Everything is recorded in the Situation Log
• Even if outdated information is removed from Facts or Status, it remains historically stored

In some situations, older information may remain if it is still operationally relevant.
However, in practice, it is more common to keep too much information visible than too little.

Overloaded Facts sections and overly long Status entries can:

• Complicate decision-making
• Create confusion
• Increase cognitive load in the command room

All functions share responsibility for maintaining a clean and current situation picture.

The primary responsibility for maintaining documentation hygiene lies with the Log-keeper, supported by the Incident Commander when structural decisions are required.

Responsibility per Platform Field

A summary table is provided at the end of this article.

Facts

Primary ownership:

Planning / Intelligence

Alternative:
Incident Commander (if no dedicated Planning function exists)

Documented by:

Planning or the Log-keeper on request

Principles:

• Only verified facts
• Clearly marked subheading if “Unconfirmed Information” is included
• No analysis
• No interpretation
• Updated continuously as new verified information becomes available

The Incident Commander must clarify early who owns the Facts field.

Assumptions (Prognosis)

Primary ownership:

Planning / Intelligence

Documented by:

Planning

Principles:

• Clearly formulated assumptions
• Must be adjustable or removable
• Should form the basis for decisions and forward planning

If no Planning function exists, the Incident Commander assigns responsibility.

Objectives (Aim & Alignment)

Primary content ownership:

Incident Commander / Operations Lead / Chief of Staff
(depending on mandate and structure)

Documented by:

Log-keeper (or Incident Commander)

Principles:

• Objectives are decided — not drafted collaboratively in text
• Must be clearly formulated
• Must be possible to follow up

The Log-keeper ensures that:

• Objectives are correctly recorded
• Changes are logged

Communication Goals

Primary ownership:

Public Information / Communications

Content decided by:

Incident Commander in coordination with Communications

Documented by:

Communications

Principles:

• How we want to be perceived
• What we want to communicate
• Tone and messaging

This field is the working space of the Communications function.

Status

Primary ownership:

Each functional lead (Operations, Planning, Logistics, Liaison, Communications, etc.)

Documented by:

Each function updates its own Status

Structural oversight:

Log-keeper

Principles:

• Each function is responsible for its own operational update
• Status must be current and concise
• Outdated Status entries must be updated or closed

The Incident Commander assigns which function owns which Status area.

The Log-keeper:

• Ensures clarity
• Reminds functions to update
• Supports when needed

Actions

Primary ownership:

The function responsible for execution

Documented by:

The responsible function

Principles:

• The action owner documents the action
• Status is updated continuously
• Completion is clearly marked

The Incident Commander ensures that:

• Decisions lead to actions
• Nothing is overlooked
• Actions are linked to objectives or decisions

Involved Actors

Primary ownership:

Liaison / Coordination

Documented by:

Liaison
Supplemented by other functions when relevant

Principles:

• Document external and internal stakeholders
• Include relevant coordination interfaces

Files

Responsibility:

Each function is responsible for uploading relevant documents connected to the incident.

Examples include:

• Situation briefings
• Decision documents
• Meeting minutes
• Structured coordination meetings
• External reports
• Maps, images, analytical documents

Naming Convention

File names must follow a predefined structure.

Example:

Situation Briefing 2026-02-20 13:00
Logistics Coordination Meeting 2026-02-20 15:30

The structure should always include:

• Type of meeting/document
• Date (YYYY-MM-DD)
• Time

This ensures:

• Easy searchability
• Chronological order
• Traceability
• Reduced duplication

The Log-keeper ensures the naming structure is followed,
but each function is responsible for uploading and naming its own documents correctly.

Summary – Responsibility Overview

Here you will find a comparison with the ICS, JESIP, and NATO frameworks for reference:

LINK to the article.

The Special Responsibility of the Log-keeper

Regardless of structure, the Log-keeper ensures:

• Structural integrity
• Clear documentation of decisions
• A traceable incident timeline

The Log-keeper does not necessarily write everything —
but is always responsible for ensuring that documentation happens.

Important at the Start of an Incident

The Incident Commander should clarify early:

• Who owns the Facts field?
• Who owns each Status area?

If this is clarified early, the work becomes more efficient and less stressful.