Documenting security logging means writing down four things: what you log, where those logs are kept and for how long, who looks at the alerts they produce, and how each decision about an alert is recorded. Alert triage documentation adds the handover, so that whoever picks up next knows what the last person decided and why. Both are paperwork exercises and both can be done in a single sitting once you have decided the answers.
This article is general information about security administration and recordkeeping. It is not legal, compliance or security advice. Which frameworks and obligations apply to an organization varies by industry, size and jurisdiction, and those questions belong with a qualified professional who knows your situation.
What follows is process and documentation only. It covers the decisions you record and the records you keep, not how any particular system is set up.
Decide and write down what your security logging covers
Start from the list of systems you already maintain and work out which ones produce a record worth keeping. The useful question is not “can this be logged” but “would I want to be able to answer a question about this later”.
For a small business, the categories that earn their place are usually these:
- Sign-in activity — successful and unsuccessful, on email, your identity directory, and anything holding customer or financial data.
- Changes to permissions and accounts — who was added, removed or had their access level changed, and by whom.
- Administrative actions — configuration changes in the systems that matter, especially ones made outside normal hours.
- Data movement — bulk exports and large downloads from systems holding customer records.
- Backup and restore activity — whether each run completed, and the record of any restore.
- Equipment and device enrollment — devices added to or removed from company systems.
Write the list down with one line per category stating which system it comes from and what the record is used for. The second half of that sentence is what limits the list. If you cannot name a question the log would answer, leave it off for now.
Also write down what you have decided not to log, with a short reason. A documented omission is a decision; an undocumented one looks like an oversight.
Note what sits inside each log entry
For each category, record what fields you expect to find: timestamp, the account involved, the action, and where it came from. You are not specifying a format, you are recording what you can rely on being there, so that a future reader knows whether a question is answerable from the record or not.
Note the time zone too, and whether it is consistent across sources. Mismatched time zones are the single most common reason a set of logs cannot be read together, and the fix is a line in a document rather than a technical project.
Record where logs are kept and for how long
Three facts per source, written in one table, settle most of the questions anyone will ask you about your security logging.
| What to record | Why it matters |
|---|---|
| Source system | Identifies where the record originates |
| Storage location | Where someone would go to read it |
| Retention period | How far back a question can be answered |
| Who can read it | Shows the record itself is access-controlled |
| Who can change or delete it | Should be a shorter list than the readers |
| Export method | How a copy is produced if one is needed |
Retention is the row that needs a real decision rather than a default. Pick a period you can actually sustain for each source and write it down, including the short ones. “Sign-in activity: ninety days, which is what this system keeps” is an honest entry. Writing “one year” because it sounds better, when the system holds thirty days, produces a document that fails the first time it is checked.
Where retention is shorter than you would like, note it as a known limitation with a review date rather than leaving the row blank. Known limitations are manageable. Unknown ones are not.
Keep the read list and the change list separate. The reason is purely about the integrity of the record: a log that the same small group can both read and quietly alter is a weaker record than one where changing it requires someone else.
Define who looks at alerts and what they decide
An alert nobody owns is a notification, not a control. Write down who is on duty for alert review, on what pattern, and what they are expected to do.
Keep the roles explicit:
- Who reviews alerts on a normal working day, by name or by role.
- Who covers when that person is away, and how the handover happens.
- Who they escalate to when a decision is above their authority, by name.
- What gets escalated — write three or four concrete triggers rather than “anything serious”.
Avoid writing any promise about how quickly an alert is looked at. The policy should describe the pattern of review, not a commitment you would have to meet on a bad week, and a documented pattern you actually follow is worth more than a target you do not.
Give the reviewer a short, fixed set of outcomes so decisions are comparable across weeks and across people. Four is usually enough: closed as expected activity, closed after checking with the person involved, escalated, or held open pending information. A fifth outcome, suppressed as a known recurring alert, is worth having as long as every suppression carries an owner and a review date, or the suppression list quietly becomes the place alerts go to be forgotten.
How to write down a triage decision
The record of a decision should be short enough that someone writes it every time and complete enough to be read cold in six months. Six fields do it:
- Date and time the alert arrived and when it was reviewed.
- What the alert was, in plain language rather than the system’s own wording.
- Who reviewed it.
- What they checked — the two or three things they looked at to reach the decision.
- The outcome, from your fixed list.
- The reason, in one sentence.
Field four is the one people skip and the one that gives the record its value. “Closed as expected activity” tells a future reader nothing. “Closed as expected activity; confirmed with the account holder that she was traveling that week” is a record that stands on its own.
Keep the log in one place, appended chronologically, and never overwrite an entry. If a decision turns out to be wrong, add a new entry correcting it and reference the original. The correction trail is evidence of a working process rather than an embarrassment.
Review a sample of closed entries once a month. Reading five at random tells you whether reasons are being written or whether the log has degenerated into a column of identical outcomes.
Write the handover notes between whoever is on duty
Handover is where small businesses lose the thread, because duty usually passes informally between two or three people who assume the other one knows.
Keep the handover note to five lines and write it every time duty changes:
- What is still open, with the entry reference for each.
- What was escalated and who now holds it.
- Anything suppressed during the period, and until when.
- Anything expected in the coming period, such as planned maintenance or a staff member traveling, that would otherwise look unusual.
- Anything the next person should chase, with a name against it.
That fourth line saves more wasted effort than the rest combined. Most alerts that turn out to be expected activity were expected by somebody, just not by the person reading the alert.
Keep the handover notes with the triage log rather than in a separate channel. Together they form a continuous account of what was seen and what was decided, which is the thing you are really building.
Keeping your security logging documentation honest
Review the whole set once a year, and sooner when you add a system, change who is on duty, or find a question you could not answer from the records. Note the review date and what changed, and keep superseded versions.
Three warning signs are visible from the documents themselves: the suppression list is growing, the triage log has stretches with no entries, or the retention column has not been checked against what the systems actually hold.
To see how your logging and triage records compare with the rest of your security administration, work through the Free Cyber Security Scorecard page on this site and start wherever it shows the biggest gap.