What an activity log provides

An access log retains relevant events occurring in a system: authentication, viewing, changes, exports or permission changes, depending on its configuration. It helps investigate incidents and check that controls operate. It should not be confused with a backup: knowing a document was deleted does not allow recovery unless another preservation mechanism exists.

Data needed to interpret an event

A useful event identifies the account or actor, operation, resource, time and outcome. Context about origin and application may be needed. Clocks and time zones should enable the sequence to be reconstructed. A generic message such as error or successful access, without enough context, may be useless when connecting events across the portal, directory and other services.

Logging without multiplying sensitive data

The log itself can contain personal information. Passwords, tokens, clinical results and complete documents should not be copied into diagnostic messages. Health information confidentiality also applies to this flow. What the security team needs and which information must remain outside general logs or under specific controls should be defined.

Integrity, access and retention

Events need protection against unauthorised modification or deletion, with access limited to defined responsible people. Retention is justified by purpose, obligations and risk, rather than imposing a universal period on every system. Continued logging must also be checked: a silent interruption can leave no evidence for precisely the period later requiring investigation.

Investigation example

In a hypothetical example, an unusual export of assessments from several workplaces is detected. Logs allow the account, scope and timing to be connected and compared with an authorised task. Analysis should establish the facts before attributing behaviour to a person: a shared or compromised account can mean the recorded identity does not correspond to the actual actor.

From evidence to response

Storing events without reviewing them is not equivalent to detecting incidents. Reasonable alerts, responsibilities and an evidence-preservation procedure should be defined. Traceability in OSH includes understanding what changed and why; technical logs are part of that explanation, not automatic proof that the whole process was performed correctly.