Logging and Session Records: Who Did What, and When

Monday, 08:50, at Bluewater Bank. Farah, who runs the three-person desk, opens an e-mail from the compliance officer that begins "It has been noted that a remote session occurred." On the fourteenth of last month, someone connected to Rhea's workstation in treasury for twenty-six minutes. Rhea does not remember a session. Compliance would like to know who it was, why, and what they did, by lunchtime. Farah opens the remote support tool's log and filters by Rhea's machine: account d.okafor, device TRS-014, 14:02 to 14:28. She searches the ticketing tool for Rhea's tickets that week and finds 7721, "spreadsheet macro error on the liquidity report". It has a session note by Daniel: asked Rhea by phone at 14:00, agreed; connected 14:02; re-registered the macro library; Rhea ran two reports to test; disconnected 14:28 with Rhea watching. Farah forwards both to compliance at 08:56, and phones Rhea, who says "oh, that, yes, the macro thing" and is slightly embarrassed.

Six minutes, because there were two records and they agreed. At a desk with only the tool's log, that e-mail is a week of asking three technicians what they remember about a Tuesday afternoon last month. They remember nothing, because it was a Tuesday afternoon last month. A session record is the account of one remote session that the organisation can read without the technician's help. It says who connected, to which device, when, with whose agreement, to do what, and how it ended. It is always made of two parts, the tool's own log and the note in the ticket, and this article is about both. It is part of our Remote Support Tooling series, which starts with the five principles in Remote Control Done Securely. Logging is the third of them, and the one that turns the other four from intentions into evidence.

It starts with why there are two records and not one, then what the tool logs and what it cannot. Next comes the note in the ticket, line by line. After that comes retention, meaning how long to keep what and who decides. It then explains who reviews the records and what they look for. Next comes reconciling the two records, with a table of mismatches. Next is the session that is questioned a month later. It ends with a short war story and the session note to copy.

Two Records, Not One

The tool's log is the mechanical record. It is written by the software, not the technician, and it says that account d.okafor connected to device TRS-014 at 14:02 and disconnected at 14:28. It is accurate to the second, impossible to forget to write, and almost impossible to read with any understanding, because it does not know why anything happened. It will tell you that a file was transferred. It will not tell you that the file was the fixed macro library, or that Rhea asked for it.

The ticket note is the human record. It is written by the technician, at the time, in sentences. It says what the session was for, that the user agreed, what was done, and how it ended. It carries meaning and it carries the consent, which no tool can record because consent is a thing a person says. Its weakness is that it is written by a person, which means it can be skipped, delayed, or reduced to the word "sorted" at five o'clock on a Friday. I know this because I once wrote "sorted" as a session note. Eight months later I was asked what I had sorted, for whom, and why the session had lasted fifty minutes. I had no idea. I write longer notes now.

Neither record is enough alone, and the desk needs them to agree. The log without the note is a list of times with no reasons; the note without the log is a set of claims with no proof. Together, each checks the other: the log proves the session happened when the note says, and the note explains the session the log shows. The whole of this article is about producing both every time and making sure, now and then, that they match.

What the Tool Logs, and What It Cannot

Most remote support tools log the same core facts for every session. They record the technician's account, the device connected to, and the start and end times. They also record whether the session was attended, with a person present who accepted a prompt, or unattended. Many also log whether files were transferred and in which direction, and whether the technician raised their rights to administrator during the session. Those tools also log whether the clipboard was used, and the text of any chat between technician and user. Some can record the whole session as video. Check what yours keeps, because the list varies, and write it down in the policy so that nobody has to guess under pressure.

What the tool cannot log is anything that happened outside it. It does not know that Daniel phoned Rhea first, or what Rhea said. It does not know that the ticket existed, unless the tool and the ticketing system are joined, which on most small desks they are not. It does not know what the technician was trying to achieve or whether it worked. And it does not know what the user saw, which is the thing a complaint is usually about. Every one of those gaps is filled by the note, which is why the note is not optional paperwork but half of the record.

Session recording, where the tool keeps a video of the screen throughout, deserves a deliberate decision rather than a default. A recording is the most complete record possible and also the most sensitive thing the desk will ever store. It contains every window that was open on the user's screen, including the ones the technician was careful not to look at. If you record, the recordings need the same protection as the most sensitive data in the organisation. They also need a retention period someone has agreed, and a reason that is better than "we might need it". Many desks are better served by a good log and a good note. Decide on purpose, write the decision down, and tell users what you do, because they will ask.

The Note in the Ticket

The session note is a short block in the ticket, written at the time, with the same lines every time. That lets a stranger find each fact where they expect it. The lines start with the consent, meaning who was asked, how, when and what they said. Next is the connection, meaning the start time and the device. Then comes what was done, in plain sentences, one per action that changed something. Next is anything moved, meaning files transferred and in which direction, or "none". Then come any raised rights, meaning whether an administrator account was used and for which step, or "none". Next is the end, meaning the time, who ended it and whether the user was watching. Last is the user's confirmation that the thing works, or that it does not and what happens next.

Seven lines, and most of them are a few words. The whole note for Daniel's session is under eighty words and took him two minutes. That is two minutes against the twenty-six the session lasted and the six it saved Farah a month later. Write it before the next ticket. Not after lunch. Not "when it's quiet". There is no quiet, and the note written at five o'clock from memory is the note that says "sorted".

The session note is not the resolution note, and the two should not be confused. The resolution note says what was wrong and what fixed it, for the next person with the same problem, and its craft is in Resolution Notes Worth Reading Later. The session note says what happened on the user's computer while the desk was connected to it, for the person who asks a month later. A ticket with a remote session has both, and they overlap in one line, the "what was done", which is fine. The session note is one of the ticket's working notes, written as the work happens. It follows the same standard as every other note on the desk, which is the subject of A Ticket Note Standard. If you run QuerySolv, the note goes into the ticket's event history like any other internal note. The consent, the session and the resolution then sit under one ticket number in the order they happened. That is exactly the order a reviewer wants them in.

Retention: How Long, and Who Decides

Retention is how long a record is kept before it is deleted, and for session records it is a decision the desk should not make alone. The organisation usually has someone who owns how long records are kept. They may work in finance, in compliance, or in the legal function. Or they may be the manager who signs the policies. The right move is to ask them, propose a period, and write down what they say. The proposal is simple: keep session logs and session notes for at least as long as tickets are kept. A session record with no ticket to attach to is a mystery. A ticket whose session has been deleted is an unanswerable question.

The complication is that the two records live in different places with different clocks. Ticket notes live as long as the ticket does, which on most desks is years. The tool's log lives as long as the tool keeps it. The period may come from a setting, a licence condition, or a default nobody has looked at. It may be far shorter than you assume. Find out what yours is. If it is shorter than the ticket retention, export the log on a schedule to a file in a folder the desk controls. Monthly is enough. That lets the mechanical record outlive the tool's memory of it. Logs age out. They do it quietly, at night, in the order you will need them.

Recordings, if you keep them, need a shorter period and a firmer one, because of what they contain. A common pattern is to keep recordings only until the session's ticket is closed and confirmed, then delete them unless a question has been raised. In that pattern, the log and the note are kept for the long period. Whatever you choose, the period goes in the policy, the deletion actually happens, and someone checks once a year that it does. A retention period that is written down but not enforced is a liability with a date on it.

Who Reviews, and What They Look For

Records that nobody reads protect nobody, so the desk reviews a sample every month, and the reviewer is, wherever possible, not the person who did the sessions. On a three-person desk that is the lead reviewing the other two and someone outside the desk, the security owner or the lead's manager, reviewing the lead's. The review is not an investigation. It is twenty minutes with the log export, the ticketing tool and a cup of something, and it asks the same questions every month so that the answers can be compared.

The reviewer picks ten sessions at random from the month's log and looks each one up in the ticketing tool. For each, they check: is there a ticket, and does it have a session note? Do the times in the note match the log within a few minutes? Does the note record consent? If the log shows a file transfer or raised rights, does the note mention it? Did the session end with the user watching? Then they look at the log as a whole for things the sample would miss. They look for any session outside working hours or longer than an hour. They also look for any unattended session on a device that is not in the unattended register. And they look for any session by an account belonging to someone who has left. The register and what belongs in it are in Unattended Access: When, Where and Who.

The review's output is a short note, kept with the policy, saying what was sampled, what matched, what did not and what was done about it. Most months it says "ten sampled, ten matched, no exceptions". That sentence is worth having, because it is what you show compliance when they ask whether anyone looks at this. The months that say something else are the ones that improve the desk. A session with no ticket is a conversation with a technician about habit, not a disciplinary matter, the first time. A pattern of them is a different conversation. The review exists to tell the two apart.

Reconciling the Two Records

Reconciling means laying the log and the tickets side by side and accounting for every difference. The differences fall into a small number of kinds, each of which means something specific. The table lists them. A healthy desk sees the first row almost always and the others rarely. A desk that has never reconciled sees all of them the first time and should not be alarmed. The point of the first reconciliation is to find out which habits need fixing.

Do the first reconciliation over a whole month and expect it to take an afternoon. After that, the monthly sample of ten takes twenty minutes, and the whole-month version is for the annual review of the tool or for the day compliance asks. Keep the table's first row as a running number: sessions sampled, sessions matched. It is the only remote support metric most desks need, and it is one that gets better by being watched.

The Session Questioned a Month Later

The question arrives, as compliance questions do, in the passive voice, and it arrives about a session nobody remembers. The procedure is the one Farah followed, and it has four steps. Find the session in the log by device and date, and note the account and the times. Find the ticket by the user's name and the date, and read the session note. Compare them: do the times match, does the note explain the session, does it record consent, and does it account for anything the log shows. Then answer the question in plain words, attaching both records, within the hour.

When the records agree, the answer writes itself, and the user, reminded, usually says "oh, that". When they do not agree, the answer is still honest, and it is written the same day. "The log shows a twenty-six minute session by d.okafor on TRS-014 on the fourteenth. There is a ticket from Rhea that day, but the session note is missing. Daniel recalls the session was to fix the macro library and that Rhea was present; we have asked him to write the note now, marked as late, and we have added a check for missing notes to the monthly review." Nobody enjoys sending that. It is a far better message than a week of silence followed by a reconstruction. It answers the only question compliance really has: whether the desk knows what happens on its own sessions.

The user's memory is not a log, and neither is the technician's. (Yours is not either, whatever you believe about it in the moment.) A month is long enough for an honest person to forget a session entirely, and a year is long enough to forget the user. The records exist because memory fails everyone equally, and the desk that writes the note at the time is the desk that never has to say "we think it was probably".

A Short War Story: The Overwritten Drawing at Redbrook Engineering

At Redbrook Engineering, an engineer called Petra reported a problem in the third month of a project. A client's foundation drawing on the shared drawing server had been replaced by an older version. The project manager asked the desk whether anyone had connected to that server around the date the file changed. The desk's remote support tool kept its log for two months unless it was exported. Nobody had ever exported it, so the log for the month in question had already gone. The only ticket near the date that mentioned the drawing server was one from Petra's colleague about a licence error. Its note read, in full, "fixed remotely", which the project review described as "brief". The technician, Jonas, thought he might have copied a file back from a backup during that session, but could not say which file or which version. The desk could not prove or disprove that the session had touched the drawing at all. Reconstructing the correct drawing from the engineers' local copies took two people most of a fortnight. The client was told the drawings were being re-issued, and the project manager's confidence in remote support was gone for a year. The lesson went into the policy in one line: a log you cannot read next quarter is not a record, and a note that says "fixed" is not a note.

The Session Note

The template below is the seven-line note, with a line for the ticket and the device at the top. That lets it be read on its own if it is ever copied out of the ticket. Write it as an internal note at the time: the consent line before you connect, the rest as you go or immediately after you disconnect. Where a line does not apply, write "none" rather than leaving it blank, because a blank says "forgot" and "none" says "checked". The same block works for a phone-and-photo session with a home worker, with "connected" replaced by "call started".

SESSION NOTE — ONE PER REMOTE SESSION, IN THE TICKET
Ticket: ________   Device: ______________   Technician: ______________

Consent:     Asked ______________ by [phone / ticket / in person] at ______.
             Answer: ______________.  Told how to end the session: [ ]
Connected:   ______ (time)   Attended / unattended: ______
             If unattended: register entry ______, approved by ______________
Done:        1. ___________________________________________________
             2. ___________________________________________________
             3. ___________________________________________________
Moved:       Files transferred: none / ______________ (direction: to / from device)
Rights:      Administrator account used: none / for step ____ only
Ended:       ______ (time)   by [me / user]   User watching: [ ]
Confirmed:   User checked ______________ and it works: [ ]
             Not yet working; next step: ______________
Written at:  ______ (if later than the session, say so: "written late")

Daniel's note on ticket 7721 is this template filled in, and it is the reason Farah's Monday was six minutes long instead of a week. It is also the reason Rhea, when she was phoned, was embarrassed rather than worried. The note told her what had happened on her own screen, in a technician's words, a month after she had stopped thinking about it. That is what the record is for. Not for the day it is written, when everyone remembers, but for the day a month later when nobody does and someone, in the passive voice, has noted that a session occurred.

Frequently Asked Questions