Most businesses generate far more security data than they realize.
Every login attempt, account change, system error, administrative action, endpoint alert, and network connection can leave a record somewhere.
The problem usually isn’t whether logs exist.
The problem is whether you’re collecting the right logs, keeping them long enough to matter, and paying attention when those logs tell you something important.
Collect everything and you create noise.
Collect too little and you may discover after an incident that the information needed to understand what happened was never recorded.
Good security logging sits somewhere between those extremes.
For a small business, the objective isn’t to build a massive Security Operations Center. It’s much simpler:
If something suspicious happens, will you have enough information to recognize it, investigate it, and make a decision?
What Is a Security Log?
A log is simply a record of something that happened within a system.
That could be:
- A user successfully logging in
- A failed authentication attempt
- An administrator creating an account
- A security setting being changed
- An application generating an error
- Malware being detected
- A firewall blocking a connection
- A file being modified
- A user being added to a privileged group
Individually, many of these events are completely normal.
Their security value comes from context.
A failed login isn’t particularly interesting by itself. People mistype passwords every day.
Fifty failed logins against multiple accounts in a short period of time tell a different story.
A successful login isn’t inherently suspicious either.
But a successful login following repeated failures, from an unusual source, against a privileged account at an unexpected time deserves a closer look.
That’s why effective security monitoring isn’t just about collecting events.
It’s about being able to ask useful questions of them.
Start With Authentication
If I had to choose one category of security logging for a small business to get right first, authentication would be near the top of the list.
Accounts are gateways into business systems.
You should have visibility into activity such as:
Successful logins. Who accessed the system, when, and from where?
Failed logins. Which account was targeted and how frequently?
Account lockouts. Why was an account repeatedly failing authentication?
MFA events. Were authentication challenges successful, denied, or unusual?
Password changes and resets. Who initiated them?
Privileged authentication. When are administrative accounts being used?
None of these events automatically proves malicious activity.
They provide evidence that can be combined with other information.
A Failed Login Is a Good Example
Windows records failed authentication activity in its Security log. One event commonly associated with failed logons is Event ID 4625.
That event can provide information about the account involved, the system where the attempt occurred, the logon type, failure reason, and other authentication details.
Suppose you see:
Event: Failed authentication
Account: Administrator
Workstation: WS01
Logon type: Interactive
Reason: Incorrect passwordThat doesn’t automatically mean someone is attacking the workstation.
Someone could simply have entered the wrong password.
But now imagine you see hundreds of similar events.
Or attempts against several usernames.
Or repeated failures followed by a successful login.
The individual event hasn’t changed.
The context has.
That’s where logs become useful for security rather than simply existing as technical records.
Account and Privilege Changes
Authentication tells you who is trying to get in.
Account-management logs help tell you when the rules governing access change.
Businesses should consider monitoring events involving:
- New user accounts
- Deleted accounts
- Disabled or enabled accounts
- Password resets
- Permission changes
- Administrative group membership
- Changes to privileged roles
- MFA configuration changes
These events matter because attackers don’t always remain dependent on the access they originally obtained.
If someone compromises an account and then creates another administrator, that second account can provide persistence even after the original password is changed.
Likewise, adding an ordinary user to a privileged group can dramatically change what that account is capable of doing.
An account change isn’t necessarily malicious.
But important access changes should be visible and attributable.
Endpoint Security Events
Laptops and desktops are where employees interact with email, files, browsers, applications, and business data.
That makes endpoints an important source of security information.
Useful endpoint telemetry can include:
- Malware detections
- Security software alerts
- Process execution
- Software installation
- Security configuration changes
- Suspicious scripts
- File integrity events
- Firewall activity
- Device connections
How much of this you collect should depend on the environment.
Logging every possible process and system event across every device can generate enormous amounts of data.
The goal isn’t maximum collection.
The goal is enough visibility to investigate meaningful activity.
Process Execution Can Tell a Story
Knowing that someone successfully authenticated tells you an account was used.
Knowing what happened afterward can be even more valuable.
Process execution logging records programs and commands executed on a system.
This can help answer questions such as:
What program launched?
Which user executed it?
What process started it?
Was PowerShell involved?
Did an unexpected administrative utility run?
Did a suspicious process appear shortly after an unusual login?
Again, context matters.
PowerShell isn’t malware.
Administrators and legitimate software use it constantly.
But unusual PowerShell activity combined with other suspicious events may deserve investigation.
Security monitoring becomes much more useful when events can be correlated instead of judged in isolation.
Cloud and SaaS Activity
For many small businesses, the most important infrastructure isn’t sitting in an office.
It’s in Microsoft 365, Google Workspace, cloud storage, accounting platforms, CRM systems, and other SaaS applications.
That means cloud activity deserves visibility too.
Depending on the platform, useful events can include:
- Authentication attempts
- MFA changes
- New devices
- Administrative actions
- Permission changes
- Mailbox forwarding rules
- File sharing
- Application authorization
- Unusual geographic access
- Account recovery changes
If most of your business operates in cloud applications but your monitoring only covers office computers, you’re watching the wrong part of the environment.
Firewalls and Network Devices
Network logs provide another layer of context.
Firewalls, VPNs, routers, wireless infrastructure, and other network devices may record:
- Allowed and blocked connections
- Remote-access sessions
- VPN authentication
- Connection sources
- Destination systems
- Firewall rule changes
- Administrative access
- Network anomalies
Not every blocked connection deserves investigation.
Internet-connected systems are constantly scanned.
The useful question is whether network activity helps identify something meaningful within the context of your environment.
For example, a firewall block may be routine.
A connection from an internal endpoint to an unexpected external destination immediately after suspicious process activity is more interesting.
Don’t Forget the Systems That Matter Most
Logging priorities should follow business risk.
Ask:
Which systems would hurt the most if compromised?
A domain controller deserves visibility.
So does a financial system.
So does the cloud platform containing customer information.
So does the identity provider controlling access to everything else.
A small business doesn’t necessarily need identical logging across every device.
Critical systems should generally receive greater visibility because their compromise creates greater consequences.
Centralized Logging Changes What You Can See
Logs stored only on individual machines have limitations.
If an organization has twenty endpoints, investigating activity across twenty separate event viewers quickly becomes inefficient.
Centralized logging brings relevant security information into one place.
A SIEM — Security Information and Event Management platform — can collect and analyze events from multiple systems.
The basic flow looks something like this:
Endpoint / Server / Cloud Service
↓
Security Logs
↓
Central Collection
↓
Detection Rules
↓
Alert / InvestigationThe value isn’t simply having another dashboard.
It’s being able to correlate activity across systems.
An authentication event on one machine may not mean much.
Combine it with endpoint activity, account changes, and network activity and you may have a much clearer picture.
Collection Is Not Detection
This distinction matters.
Logging records activity.
Monitoring observes that activity.
Detection identifies activity that may require attention.
Investigation determines what actually happened.
A company can have extensive logging and still have poor security visibility if nobody reviews it or meaningful detections haven’t been configured.
Likewise, a security product can generate hundreds of alerts without providing useful visibility if nobody can distinguish important events from noise.
The goal isn’t to produce more alerts.
It’s to make important activity easier to recognize.
More Logs Can Create Less Visibility
This sounds contradictory, but it’s a common problem.
Imagine collecting millions of events every day with no prioritization.
Technically, you have tremendous visibility.
Operationally, you may have almost none.
Important events disappear into noise.
Storage costs increase.
Investigations become slower.
Analysts or administrators begin ignoring alerts because too many of them don’t matter.
This is why logging strategy should start with questions rather than tools.
What activity would we need to investigate?
Which accounts matter most?
Which systems matter most?
What behavior would concern us?
What evidence would we need after an incident?
Then determine which logs answer those questions.
How Long Should Logs Be Kept?
There isn’t one correct retention period for every business.
Retention depends on factors such as:
- Regulatory requirements
- Storage capacity
- Business risk
- Cyber insurance requirements
- Incident investigation needs
- Type of system
- Sensitivity of information
The important thing is to make retention intentional.
If logs disappear after seven days simply because nobody changed a default setting, you may discover during an investigation that the evidence you need is already gone.
The opposite extreme isn’t necessarily better.
Keeping enormous quantities of low-value data forever creates cost without automatically improving security.
Retention should have a reason behind it.
Protect the Logs Too
Logs themselves can become security targets.
An attacker who gains administrative access may attempt to delete or alter evidence of their activity.
Centralized logging helps because copies of important events can exist somewhere other than the compromised endpoint.
Access to security logs should also be controlled.
Not every employee needs permission to modify logging configurations or delete security records.
If logs are going to serve as evidence during an investigation, their integrity matters.
What Should a Small Business Log First?
If you’re starting from limited visibility, don’t try to solve everything at once.
Prioritize:
Authentication and identity activity
Logins, failures, MFA events, account changes, and privileged activity.
Critical endpoints and servers
Security alerts, important system changes, and relevant process activity.
Cloud platforms
Authentication, administrative changes, permissions, and suspicious account behavior.
Security infrastructure
Firewalls, VPNs, endpoint protection, and other controls already generating useful telemetry.
Critical applications
Especially systems handling financial, customer, employee, or otherwise sensitive information.
Then expand visibility as the environment and monitoring capability mature.
The Question Your Logs Should Answer
A logging strategy shouldn’t begin with:
“How much data can we collect?”
It should begin with:
“What would we need to know if something went wrong?”
Who logged in?
What account was used?
What happened afterward?
Were permissions changed?
Was something installed?
Did sensitive information move?
Did another system see related activity?
Can we reconstruct the sequence?
Those are investigation questions.
Your logs should help answer them.
Visibility Before Complexity
Small businesses don’t necessarily need enormous security operations platforms or teams staring at dashboards around the clock.
They do need enough visibility to avoid operating completely blind.
Start with the systems and identities that matter most.
Collect useful events.
Centralize important information where appropriate.
Create detections around meaningful behavior.
And make sure somebody knows what to do when something deserves investigation.
Because the objective of security logging isn’t to record everything that happens.
It’s to make sure that when something important happens, you can see it.