Logging What Was Done
The record that answers a question months later, and the difference between a log and something anybody reads.
A support operation generates hundreds of sessions. What is recorded about them determines whether a later question has an answer.
The evidence discussed in “Logging What Was Done” is useful only when it answers a named operational question. Organisations considering explore Monitask for how employees cheat time trackers can add time and workflow context, but should keep direct feedback, service outcomes and a correction process alongside every report.
What to log
Who connected, to which machine, when, and for how long.
For an independent reference related to “Logging What Was Done”, consult the ENISA cybersecurity resources; it provides a useful external check on security, privacy and operating assumptions before a process is adopted.
Against which ticket or request.
Whether control was taken or only viewing.
Whether files were transferred.
And whether the session was recorded.
Six fields, mostly automatic, and together they answer almost every question that arises.
What the log is for
Answering "who was on my machine on Tuesday".
Investigating a complaint or a suspicion.
Establishing a pattern: somebody connecting outside hours, or to machines unrelated to their work.
And demonstrating, if challenged, that access is controlled, which is increasingly asked for in audits.
Making it searchable by machine
Most platforms list by technician. The question people ask is about their own computer.
"Who connected to this machine in the last month" should be answerable in a minute.
If it is not, the log cannot answer the question it most needs to answer.
Reviewing
Monthly, briefly: connections outside working hours, connections to machines with no matching ticket, anybody whose volume is unusual.
Twenty minutes.
Without it the log is evidence after an incident rather than a control before one, which is the same distinction as everywhere else.
The unmatched-session signal
A connection with no corresponding ticket is the single most useful thing to look for.
Most are innocent: a quick favour, a test, a colleague asking directly.
Some are not, and a pattern of them from one person is worth a conversation, which is easier to have early than after something happens.
Telling people it exists
Employees should know that sessions are logged and that they can ask.
It reassures, and it is also the thing that deters the small misuse that otherwise goes unnoticed.
Logging nobody knows about protects the organisation and not the person, which is a weaker arrangement.
Retention
Long enough to investigate something discovered later: months rather than days.
Shorter for recordings, which are heavier and more sensitive.
With a stated schedule rather than whatever the platform defaults to, which is usually indefinite.
What a good answer looks like
"Three connections to that machine last month: two against tickets you raised, one on the fourteenth by the imaging team as part of the refresh. Here are the times."
That answer ends a concern.
"We would have to look into it" does not.
What to check
Can you answer "who connected to this machine" in a minute?
Does anybody review the log monthly?
How many sessions have no matching ticket?
And do employees know the log exists?