Logging Made Manageable: Signals SMEs Should Watch

Logging sounds like something reserved for big security teams with wall-sized dashboards. In reality, it is much simpler. Logs are the notes your systems keep about what happened: who signed in, what changed, which device raised an alert, and whether something odd happened at 2:17 am when everyone was asleep.

The problem is that many small businesses sit at one of two extremes. Either they collect almost nothing, so incidents become guesswork, or they collect everything and drown in noise. Neither helps. Good logging is about having enough evidence to spot trouble, investigate quickly, and avoid paying to store mountains of data nobody will ever read.

A recent UK SMB security piece from ITPro highlighted the same gap from a business angle: many smaller firms are aware of cyber risk, but struggle to turn that awareness into practical monitoring and response. 

This guide explains which signals to collect, what to ignore, and how to build a simple review habit that works without a security operations centre.

Why logs matter more than most teams think

Most incidents leave clues before visible damage appears. A strange sign-in from a new country. A new inbox forwarding rule. A user added to an admin group. A laptop that suddenly starts blocking suspicious files. A cloud folder shared with an external address.

Without logs, those clues vanish. With the right logs, they become early warning signs.

Logging also matters after something goes wrong. If a client asks whether their data was accessed, “we’re not sure” is not a comforting answer. If an insurer asks when the breach started, you need evidence, not a shrug. Logs help you answer those questions with some confidence.

They do not need to be perfect. They need to be useful.

What small businesses should log first

Start with the systems attackers are most likely to touch and the systems that matter most to the business.

1. Sign-ins and identity events

Identity logs should be top of the list. They show who signed in, from where, on what device, and whether MFA was used. Watch for:

• sign-ins from unusual countries
• repeated failed logins
• impossible travel alerts
• MFA failures or repeated prompts
• password resets
• new authentication methods added

If you only review one category regularly, make it identity.

2. Admin changes

Admin changes deserve special attention because they alter the shape of your security. Log and review:

• users added to admin roles
• permissions changed on key systems
• new service accounts
• MFA exemptions
• conditional access changes
• changes to audit settings

A normal user account being compromised is bad. An admin account being quietly upgraded is worse.

3. Email security events

Email remains a favourite route into small businesses. Keep an eye on:

• blocked phishing attempts
• malware attachments
• suspicious forwarding rules
• mailbox delegation changes
• high-volume sending from one account
• sign-ins followed by new inbox rules

This ties neatly into the controls covered in Mustard IT’s article on domain spoofing and fake invoices. Email authentication reduces spoofing, but mailbox logs are what help you spot account misuse after a successful compromise. 

4. Endpoint alerts

Endpoint logs do not need to record every sneeze. Focus on alerts that show risk:

• malware blocked
• device isolation events
• tamper protection changes
• suspicious scripts
• unapproved remote access tools
• repeated crashes of security software

The goal is to see whether a device is drifting from normal behaviour.

5. File and data access

For sensitive areas, log who opened, downloaded, deleted or shared files. This is especially useful for finance, HR, leadership documents and client folders.

Do not review every file event manually. Instead, look for unusual patterns: bulk downloads, external sharing, access outside business hours, or activity from accounts that should be inactive.

What you can safely ignore at first

A common mistake is trying to collect everything from day one. That creates cost and alert fatigue.

For most small businesses, you can delay deep logging of low-risk systems, highly repetitive application events, routine successful file opens, and noisy infrastructure events that nobody understands. Keep the door open to collect them later, but do not start there.

Logging should answer business questions. If a log source cannot help answer “what happened, who did it, and what changed?”, it may not deserve priority yet.

Build a review habit

The best logging system is useless if nobody looks at it. The review does not need to be long. Fifteen to twenty minutes at a sensible interval is enough to spot many early warnings.

A simple review could cover:

• unusual sign-ins
• new admin users or role changes
• MFA failures and exemptions
• suspicious mailbox rules
• endpoint alerts that remain unresolved
• new external file shares
• disabled logging or missing data

Pick a regular slot. Tuesday morning can work well because it catches the weekend without colliding with Monday chaos, but the exact timing matters less than ownership. Assign a named owner and a deputy. If nobody owns the review, it will not happen.

Sumo Logic’s 2026 SIEM guidance makes a useful point here: value comes from collecting the right sources, correlating events, tuning alerts, and making reviews sustainable, not from dumping every event into a tool and hoping insight appears. 

How long should logs be kept?

There is no single answer, but there is a sensible starting point.

For many small businesses, keep high-value security logs for at least 90 days, and aim for six months where cost allows. Identity, admin, email and endpoint logs are the first candidates for longer retention. Low-value noise can be shorter.

The key is matching retention to likely questions:

• Can we investigate something reported last month?
• Can we see whether a leaver accessed data before departure?
• Can we check whether a suspicious sign-in happened before invoice fraud?
• Can we satisfy basic insurer or client questions after an incident?

Do not keep logs forever because storage feels cheap. Logs can contain personal data, filenames, IP addresses and behaviour patterns. Storing them creates responsibility.

Protect the logs themselves

Logs are evidence. Treat them accordingly.

Attackers often try to hide by deleting logs, disabling audit settings, or using accounts that are not monitored. That means log storage needs basic protection:

• limit who can delete or alter logs
• alert when logging is disabled
• keep admin logs separate from normal user access
• export critical logs to a location attackers cannot easily alter
• review who can access the log platform

A practical rule: nobody should be able to commit the crime and erase the record without leaving another trace.

Turning noise into useful alerts

Alerts should be rare enough to matter. If staff see dozens every day, they stop caring.

Start with a small set:

• new global admin created
• MFA disabled or bypassed
• impossible travel or risky sign-in
• mailbox forwarding to an external address
• multiple failed logins followed by success
• security agent disabled
• bulk file download from a sensitive folder
• audit logging changed or stopped

Each alert should have an owner and a first action. For example: “If an external forwarding rule appears, disable it, reset the password, revoke sessions, check recent sent items.”

Logging and incident response belong together

Logs are not just for spotting incidents. They help you handle them.

If ransomware hits, logs show the first affected device, the accounts involved, and whether the attacker moved sideways. If a mailbox is compromised, logs show forwarding rules, suspicious sign-ins and whether the account sent messages externally. If a supplier payment looks wrong, logs may show whether finance credentials were used from an unusual location.

This is where logging connects directly to your response plan. Mustard IT’s cyber incident playbook explains what to do when something goes wrong; good logs give that plan the evidence it needs. 

Without logs, response becomes storytelling. With logs, it becomes investigation.

A simple 30-day logging plan

If logging feels messy, start with one month.

Week 1: list your key systems: email, identity platform, endpoint protection, file sharing, finance and CRM. Confirm which ones already produce logs.

Week 2: turn on useful logs: sign-ins, admin changes, mailbox rules, endpoint alerts and external sharing.

Week 3: set retention periods and protect log access. Make sure at least two trusted people know where logs live and how to export them.

Week 4: run the first review. Note what was useful, what was noisy, and what needs tuning.

Keep the first version boring. Boring is repeatable.

What to measure

Good logging should improve visibility without exhausting the team. Track a few simple measures:

• percentage of critical systems with logging enabled
• unresolved security alerts older than seven days
• admin changes reviewed each week
• time taken to find evidence for a test incident
• high-risk alerts with a written first action
• log sources that stopped sending data unexpectedly

These are plain enough for an operations meeting and useful enough for an audit.

Keep compliance in perspective

Frameworks such as ISO 27001 and Cyber Essentials-aligned customer questionnaires increasingly ask whether organisations monitor access, review logs and protect evidence. Konfirmity’s 2026 summary of ISO 27001 logging and monitoring requirements notes the same principle: logging without review is not enough, and logs themselves need protection from tampering. 

That does not mean every small business needs enterprise-grade SIEM from day one. It means you should be able to show that important events are recorded, reviewed and acted upon.

Avoid these common traps

The first trap is buying a tool before deciding what you want to know. Tools help, but they cannot define your priorities.

The second is collecting logs nobody understands. If an alert requires three specialists to interpret, it may not help a small team at 5 pm on a Friday.

The third is keeping logs but never testing retrieval. During an incident is a terrible time to discover nobody can export the evidence.

The fourth is reviewing only after something goes wrong. Logs are most useful when they are part of a normal rhythm.

Final thought

Logging does not need to be overwhelming. Start with identity, admin changes, email, endpoints and sensitive file access. Keep the review short. Protect the evidence. Tune the noise. Write down what to do when an alert matters.

Small businesses do not need every signal. They need the right signals, checked often enough to make a difference.

If you want help setting up sensible logging, reducing alert noise and building a review routine your team will actually follow, contact Mustard IT.