Ensure Event Logs Protect Sensitive Data
Event logs must keep sensitive information safe and secured.
Plain language
Event logs are like a diary of your computer systems, keeping track of what happens over time. It's crucial to ensure these logs don't accidentally reveal private information. If sensitive data leaks through logs, it could be misused by hackers, leading to data breaches or identity theft.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Event logs produced by software ensure that any sensitive data is protected.
Why it matters
If event logs expose sensitive data, attackers may use it to gain access or exfiltrate data, causing breaches, incident response costs and reputational damage.
Operational notes
Audit logging to prevent secrets/PII in logs; mask or encrypt values and restrict log access to approved admins. Periodically test by reviewing sample log entries.
Implementation tips
- System administrators should work with software developers to regularly review the type of information recorded in event logs. They can do this by setting up workshops where the team analyses logs to identify any sensitive data like user passwords or financial details appearing in them.
- IT teams should configure logging software to automatically mask any sensitive information. This can be done by setting rules within the logging software to replace sensitive data with general placeholders, like replacing credit card numbers with asterisks.
- Managers should ensure that access to event logs is limited to authorised personnel only. This means setting up permissions so that only certain people, trained in handling sensitive information, can view the full logs.
- Cyber security officers should establish clear guidelines on what constitutes sensitive data. They might organise a meeting to create a list of data types considered private, ensuring all team members understand what should be protected in logs.
- IT teams should implement log review processes to regularly check logs for any sensitive data leaks. This can involve setting up automated alerts to notify the team if sensitive data is detected in logs, prompting immediate action.
Audit / evidence tips
-
Askthe event logging policy: Request the document outlining log management procedures
Goodclearly describes how sensitive information is protected and who oversees the process
-
Aska sample of redacted event logs: Review examples of logs that have been scrubbed of sensitive data
Goodshows logs where sensitive details are either absent or appropriately obscured
-
Aska list of personnel with log access: Obtain a document or system access list showing who can view logs
Goodcomprises a short list of authorised individuals tied to necessary functions
-
Askabout training records for staff handling logs: Request documentation of training sessions on log management and data protection
Goodincludes recent, relevant training records that are regularly updated
-
Askexamples of alerts set up for sensitive data leaks: Check configurations or reports that show alerts are active
Goodindicates that alerts are properly configured and documented
Cross-framework mappings
How ISM-2052 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 8.15 | ISM-2052 requires that event logs produced by software protect any sensitive data contained within them | |
| sync_alt Partially overlaps (1) expand_less | ||
| Annex A 8.12 | ISM-2052 requires that event logs produced by software protect any sensitive data contained within them | |
E8
| Control | Notes | Details |
|---|---|---|
| sync_alt Partially overlaps (1) expand_less | ||
| E8-AC-ML2.6 | ISM-2052 requires that event logs produced by software protect any sensitive data contained within them | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.