Imagine running a business without CCTV, receipts, access records or security guards.

Someone breaks into your building overnight. You discover that something has happened – but you have very little idea:

• Who entered?
• When did they enter?
• Which room did they visit?
• What did they do?
• What did they take?
• How did they get in?

This is the problem that logging and auditing help to solve.

Systems generate enormous amounts of information about what is happening inside them. If this information is collected, protected and analysed properly, it can provide valuable evidence of both normal activity and potential attacks.

If you don’t record what happened, it can be extremely difficult to determine what happened after something goes wrong.

Logging and auditing are therefore important detective security controls, but they also support prevention, incident response, accountability and compliance.

What Is Logging?

Logging is the process of recording events that occur within a system.

A log might record:

• User logins
• Failed authentication attempts
• File access
• Network connections
• Configuration changes
• Administrator activity
• Application errors
• Security alerts
• System failures

For example:

2026-09-11 09:21:14
User: alice
Action: Login
Source: 10.10.20.15
Result: SUCCESS

Another event might look like:

2026-09-11 09:22:03
User: alice
Action: Login
Source: 185.10.20.44
Result: FAILED

Each individual record is a log entry, a collection of these records forms a log.

What Is Auditing?

Auditing is the process of examining activity and records (such as logs) to determine whether actions were appropriate, authorised and compliant with policy.

Logging records what happened – Auditing examines what happened.

A useful distinction is:

Logging creates the evidence. Auditing uses that evidence to determine what happened and whether it was acceptable.

Why Does Logging Matter?

Imagine an attacker compromises an administrator account.

They:

09:14  Login
09:16  Create account
09:18  Change permissions
09:21  Access database
09:25  Download data
09:29  Delete files

Without logging there are no useful records of this activity – so you might know something happened, but not what, or when, or how.

With good logging, you have evidence with which to investigate these things.

Logging Is Not the Same as Monitoring

These terms are often confused.

• Logging – Records events.
• Monitoring – Watches events for things that may require attention.

Logging provides the raw information.

Monitoring uses it to identify potential problems.

Logging Is Not the Same as Alerting

A system can record an event without generating an alert.

For example, a single failed log in attempt should generate an event which is logged for later analysis and reporting

But if there are: 50 failed logins, from one source, against 20 accounts, in 2 minutes…

The monitoring system might generate an alert for a possible password spraying attack.

This distinction is important.

Not every log entry should generate an alert.

If it did, security teams would quickly be overwhelmed.

What Should Be Logged?

There is no universal list of events that every system should record.

Logging should be based on:

• The purpose of the system
• Security requirements
• Risk
• Regulatory requirements
• Incident-response requirements
• Operational requirements

However, some events are commonly valuable.

Authentication Events

Authentication events are particularly important. Systems should typically record events such as:

• Successful login
• Failed login
• Logout
• Password change
• Password reset
• MFA success
• MFA failure
• Account lockout

Privileged Activity

Activity associated with Administrator accounts is particularly important to record as it provides accountability for powerful actions.

Configuration Changes

All changes to security configurations should be logged.

For example changes to Firewall rules, or trusted file locations

This can be extremely useful during an investigation to work out how an attacker moved through the network.

File Access

For sensitive systems, organisations may need to record access to important files and the actions undertaken

For example:

User: Alice
File: Payroll.xlsx
Action: READ
Time: 10:21

Or:

User: Bob
File: CustomerDatabase.db
Action: DELETE
Time: 10:43

This can help establish who accessed or modified information.

Database Auditing

Databases often contain extremely sensitive information.

Database auditing can record:

• Login activity
• Queries
• Data changes
• Privilege changes
• Administrative activity

For example:

User: application
Action: SELECT
Table: Customers
Records: 250

User: admin
Action: ALTER TABLE
Table: Customers

The exact level of database auditing should reflect the sensitivity and risk of the system.

Network Logging

Network devices can generate valuable logs.

Examples include:

• Firewall connections
• Blocked traffic
• VPN connections
• DNS requests
• Proxy requests
• Router events

Repeated attempts against many systems might indicate scanning or attack activity.

Web Server Logs

Web servers normally record all received requests.

For example:

10.20.30.40
GET /index.html
200

10.20.30.40
GET /admin
403

10.20.30.40
GET /../../etc/passwd
400

The first request is perfectly normal for HTTP traffic, however the other two requests might warrant investigation depending on the context.

Web logs can be particularly useful when investigating:

• Web attacks
• Scanning
• Authentication attacks
• Exploitation attempts
• Suspicious user activity

DNS Logging

DNS logs can provide valuable information about where systems are attempting to connect.

Malware often reaches out to unusual domains as part of their Command & Control (C2) mechanism. Similarly, some malware use Domain Generating Algorithms (DGAs) to generate thousands of random domains to connect to in attempts to avoid being blocked – rapid requests to random domains should be investigated as signs of compromised systems.

DNS monitoring can sometimes identify:

• Malware
• Command-and-control activity
• Phishing
• Suspicious applications
• Data exfiltration

Endpoint Logging

Modern endpoint security tools can record events such as:

• Process started
• File created
• File modified
• Registry changed
• USB device connected
• Network connection created
• Security control disabled

For example, MS word spawning a PowerShell process which then runs a script that reaches out to a remote domain should be classed as highly suspicious.

A sequence like this could be highly significant to a security analyst during their investigations.

Application Logging

Applications should also produce appropriate security logs.

Examples include:

• Login attempts
• Privilege changes
• Account creation
• Password resets
• Important transactions
• Administrative actions
• Security exceptions

For example:

User: Alice
Action: Change bank account
Old: Account A
New: Account B
Result: SUCCESS

This provides an audit trail for important business operations.

Audit Trails

An audit trail is a chronological record showing what happened and when.

For example an audit trail showing:

09:10  Alice logs in
09:12  Alice accesses customer record
09:15  Alice modifies record
09:17  Alice exports report
09:20  Alice logs out

allows an auditor to reconstruct the sequence of events to get a bigger view of what happened.

Audit trails are particularly important for systems handling:

• Financial information
• Personal information
• Healthcare information
• Security administration
• Critical business processes

Who, What, When and Where?

A useful principle for logging is to capture enough information to answer:

Who did what, when and from where?

For example:

• WHO? – Alice
• WHAT? – Changed firewall rule
• WHEN? – 11:42:16
• WHERE? – Management workstation
• RESULT? – SUCCESS

Depending on the system, useful additional information may include:

• Source IP
• Device
• Session
• Application
• Object affected
• Before/after values
• Reason for change

Accurate Time Is Essential

Imagine investigating an attack where various systems have different clocks.

Firewall:  10:32
Server:    10:28
Database:  10:41
Endpoint:  10:35

This makes it almost impossible to determine which event happened first?

This can make reconstructing an attack extremely difficult.

Systems should therefore use reliable time synchronisation, commonly through NTP.

Large organisations may operate across multiple countries, so using a consistent time reference can make investigation easier.

For example:

London       09:30
New York     04:30
Tokyo        17:30

TO solve this issue, security systems may store timestamps in UTC and convert them for display where appropriate.

The important thing is consistency. It doesn’t matter what approach you take, so long as every system uses the same approach.

Centralised Logging

Leaving logs on individual systems can make investigation difficult.

Not only would it be a time consuming event gathering thousands of log files from hundreds of separate systems, attacker compromising a server will often attempt to delete the local logs to remove all evidence of their attacks.

A better approach is to send logs to a remote server.

Now the organisation has a central collection of events, they can be better correlated, and will be better protected form potential compromise.

A Security Information and Event Management (SIEM) platform collects and analyses logs from multiple sources and allows security teams to see events from across the environment in one place.

One of the major advantages of centralised logging is correlation.

Individually, events might not look particularly interesting

For exmaple:

• Failed login
• Firewall connection
• PowerShell execution
• New administrator
• Large data transfer

But if they all involve the same account and device, they may indicate evidence of an attack.

Logging vs Auditing vs Monitoring

It is worth keeping the distinctions clear.

Concept	Main purpose
Logging	Record events
Monitoring	Watch events for significant activity
Alerting	Notify someone when a condition is met
Auditing	Examine activity against policy or requirements
Investigation	Determine what actually happened
SIEM	Collect, correlate and analyse events

These activities overlap, but they aren’t identical.

What Shouldn’t Be Logged?

We should understand that more logging isn’t always better.

Logs can contain sensitive information such as:

• Passwords
• Authentication tokens
• Personal information
• Financial information
• Session identifiers
• Confidential business data

Applications should not unnecessarily log sensitive information.

Log Integrity

Logs should be protected against:

• Modification
• Deletion
• Unauthorised access

Techniques can include:

• Access controls
• Centralised storage
• Write-once storage
• Cryptographic integrity mechanisms
• Digital signatures
• Restricted administrative access

The objective is to maintain confidence that The log represents what actually happened.

Separate Log Administrators

For highly sensitive environments, it can be useful to separate those who administer systems from those who manage audit records.

This supports Separation of Duties.

A system administrator shouldn’t necessarily be able to quietly modify the audit evidence of their own actions.

Log Retention

Logs are files, and files consume storage.

Organisations therefore need to determine how long should they keep log data

The appropriate retention period depends on:

• Security requirements
• Legal requirements
• Regulatory requirements
• Business requirements
• Storage costs
• Investigation needs

If logs are deleted too quickly it can make investigations much harder as there is less data to examine to determine what happened.

Keeping everything forever isn’t necessarily the answer either.

It can create:

• Storage costs
• Privacy concerns
• Data-protection obligations
• Increased exposure if logs are stolen

The principle should be – Keep what you need for as long as you have a legitimate reason to keep it.

Systems often automatically rotate logs to prevent a log file from growing indefinitely and consuming all available storage.

Building an Attack Timeline

Suppose an attacker compromises an account.

Logs might show:

08:42  Failed login
08:43  Successful login
08:44  MFA challenge
08:45  New VPN session
08:47  Privileged command
08:51  Database accessed
08:55  Large file transfer
09:02  Account disabled

This gives investigators a chronological picture of the attack.

But logging isn’t only useful for finding attacks.

Suppose someone claims “I didn’t access that database.”

An audit trail might show:

User: Alice
Database: CustomerDB
Action: SELECT
Time: 14:32
Source: Laptop-27
Result: SUCCESS

This provides evidence that the account was used, but investigators must still consider whether the account itself was compromised. Other data should be considered in an investigation.

For example:

• Was Alice on leave when the access occurred?
• Was the access from inside the organisation network, or was it remote?

Logging and Non-Repudiation

Strong audit trails can support non-repudiation – providing evidence that a particular action occurred and was associated with a particular identity.

Cryptographic techniques such as:

• Digital signatures
• Signed logs
• Cryptographic hashes

can strengthen confidence in the evidence.

However, a log entry saying “Alice” doesn’t automatically prove that Alice personally performed the action – Her account could have been compromised.

This is why strong authentication and contextual evidence matter.

Logging and Insider Threats

Logging is particularly important for detecting insider activity. Good auditing can provide accountability even when the person already has legitimate access.

Logging and Compliance

Many organisations have regulatory or contractual requirements concerning logging and auditing.

Requirements may specify things such as:

• What must be recorded
• How long records must be retained
• Who can access them
• How records should be protected
• How privileged activity should be audited

The exact requirements depend on the organisation and the systems involved.

Don’t Log Secrets

One particularly important rule concerning the data collected for logs is to Never log passwords, private keys or other sensitive secrets unnecessarily.

Examples include:

• Passwords
• API keys
• Access tokens
• Session tokens
• Encryption keys

If a secret accidentally appears in a log, the organisation may need to treat it as compromised.

Logs become targets

As mentioned above, attackers know that logs can expose their activity.

They may attempt to:

• Delete logs
• Modify logs
• Disable logging
• Flood logs with noise
• Change system time
• Compromise the SIEM
• Create misleading events

This is why the logging infrastructure itself needs to be secured.

Log Flooding

An attacker may generate huge numbers of events.

This could:

• Consume storage
• Increase processing requirements
• Hide important events
• Overwhelm analysts

Logging systems therefore need appropriate capacity and filtering.

Alert Fatigue

If a security team receives thousands of alerts every day, important alerts can get lost in the noise

Effective logging isn’t about generating the maximum amount of information – It’s about generating useful information.

Log Filtering

Systems can filter out events that have little security value.

Filtering should be done carefully so that useful forensic information isn’t discarded.

Baselines and Anomalies

Auditing can help establish what normal activity looks like and as such, identify unusual behaviours that could trigger further investigation.

Modern security systems can analyse activity for behavioural anomalies – this is commonly referred to as End User Behaviour Analytics (EUBA)

This can be particularly useful for detecting compromised accounts.

Test Your Logging

It’s surprisingly easy to assume that something is being logged when it isn’t.

Organisations should periodically test logs by asking questions such as

If an administrator:

• Creates an account
• Changes a privilege
• Changes a firewall rule
• Disables a security control

Do we have an audit record for each action?

If the answer is no, there is a visibility gap and the logging process should be reviewed.

In Summary

Logging is the recording of events. Auditing is the examination of those records to determine what happened and whether activity was appropriate.

Useful things to log include:

• Successful and failed authentication
• MFA events
• Privileged activity
• Account creation and deletion
• Configuration changes
• File access
• Database activity
• Network connections
• Firewall events
• Application security events
• Security-tool activity

A mature logging system should:

• Collect – Gather logs from important systems.
• Centralise – Send important records to protected central storage.
• Synchronise – Ensure systems use accurate and consistent time.
• Protect – Prevent unauthorised modification or deletion.
• Monitor – Look for suspicious patterns.
• Alert – Generate actionable notifications.
• Retain – Keep appropriate records for the required period.
• Audit – Review activity against security policies and requirements.
• Investigate – Use the records to reconstruct incidents and understand what happened.

Logging and auditing work closely with:

• Monitoring
• SIEM
• Incident Response
• Access Control
• Authentication
• Network Security
• Defence in Depth
• Zero Trust
• Compliance
• The CIA Triad
• The Parkerian Hexad

The most important distinction is:

Logging tells you what happened. Auditing asks whether what happened was acceptable.

• A firewall may block an attack.
• MFA may prevent an attacker logging in.
• Access controls may prevent them accessing sensitive data.

But if those controls fail, logging and auditing can provide the evidence needed to discover, investigate and understand what happened.

And that leads to a simple security principle:

If you can’t see it, you can’t reliably detect it. If you can’t record it, you may not be able to prove it.

Log it. Protect it. Monitor it. Learn from it.