I have written before about logging debt: the slow build-up of poor logging decisions that only becomes visible when something goes wrong. As part of my PhD research at the University of Plymouth, we set out to understand how developers actually approach log design, and why the same logging weaknesses keep appearing in real systems.

This post summarises our paper A Structured Approach to Log Design: Addressing Security and Compliance Gaps in Software Development, published at the International Symposium on Human Aspects of Information Security and Assurance (HAISA) 2025, with Nathan Clarke, Bogdan Ghita and Johan Van Niekerk.

The weaknesses are well documented

Logs are critical for debugging, monitoring and security auditing, and they are often the first place investigators look after a breach. Yet logging implementations remain inconsistent. The OWASP Top 10 has treated insufficient logging and monitoring as an increasingly critical risk since 2017, and sensitive data exposure, now grouped under A02: Cryptographic Failures, has persisted over the same period, frequently through logs. The Common Weakness Enumeration (CWE) catalogues the specific failures:

Previous studies of developers report the same recurring themes: logs that are too verbose or lack context, difficulty choosing log levels, and sensitive data leaking into log files. What the standards and earlier studies do not capture is the cultural and organisational side: how developers actually make logging decisions, and what gets in their way. That is the gap our survey set out to fill.

Readability comes first, security second

When designing logs, developers put readability and clarity ahead of everything else. Clear, structured logs make debugging faster, but this focus on usability often comes at the expense of security.

Around 54% prioritised keeping sensitive data out of logs, reflecting awareness of requirements such as GDPR, HIPAA and PCI DSS. Yet only 39% treated compliance as a key logging requirement, which suggests regulatory frameworks are not consistently enforced in practice. And while 37% value logs for analytics, many logs remain unstructured and hard to feed into analytics tools.

Sensitive data is still ending up in logs

A third of respondents had encountered sensitive information such as passwords, authentication tokens, API keys or personally identifiable information in log files. That is a direct violation of security best practice and regulatory requirements, and exactly the weakness described by CWE-532. Logs that hold plaintext credentials and are not properly protected become a rich target for attackers, and organisations that mishandle sensitive data in logs risk legal and financial penalties.

A major reason is training. Most developers have never been formally taught how to log securely, and rely instead on ad hoc guidelines or personal experience.

Without that training, logs either fail to capture critical security events or store so much that they enlarge the attack surface.

No standard, no consistency

Only 40% of developers work in organisations with clearly documented logging guidelines. For the other 60%, there is no consistent approach, which means a single organisation can contain vastly different logging practices and designs from one team to the next.

Few organisations adopt approaches that promote structured log design, such as the Common Event Format (CEF) or logging as code. The resulting lack of uniformity creates security blind spots, particularly in cloud environments where distributed logging is essential for detecting unauthorised access, and it makes incidents much harder to reconstruct.

Forensic gaps when it matters most

Around 45% of respondents reported difficulty investigating security incidents because logs were missing or incomplete. When failed logins, privilege escalations or unauthorised data access are never recorded (CWE-778), the forensic evidence simply does not exist.

Many organisations also purge logs too soon to trace incidents retrospectively. Forensic logging needs tamper-resistant storage, cryptographic integrity checks and centralised aggregation. Without them, attackers can erase their traces and leave responders with an incomplete record.

The vulnerabilities developers actually found

The survey shows a clear link between insecure logging practice and known vulnerabilities. Respondents described the log-related weaknesses they had encountered in their own applications and devices:

Reactive, not proactive

Despite broad awareness of logging risks, many organisations remain reactive. With 64% of respondents never trained in privacy-compliant logging, insecure practices such as logging credentials, failing to mask personal data and omitting key security events persist. Compliance tends to be treated as an audit exercise rather than a reason to build better logging, and without proactive log auditing and regular validation of logging configurations, vulnerabilities stay hidden until a breach exposes them.

Six design requirements

Together, the findings point to a widespread lack of training and standardised guidelines. Logging practices need to be standardised across teams and environments, developers need formal training in secure logging, and logs must be structured, machine-readable and rich enough in context to capture security-relevant events. They must be retained in line with detection and regulatory timelines, stored in a tamper-evident way, and written with privacy in mind so that sensitive data is excluded or masked.

From the survey and the related research, the paper sets out six design input requirements for forensic-ready logging:

These are requirements, not yet a model. They describe what must be addressed to close the gap between current practice and forensic readiness. The next step in this research is a dedicated forensic-ready logging model built on them.

The full paper is available from Springer. The same thinking also drives the OWASP Secure Logging Benchmark.