Limit logs to the minimum fields needed for operations, detection, and forensics, and avoid recording secrets, full personal data, tokens, or payment details. Apply redaction, masking, and strict access controls to log pipelines and storage. Excessive logging increases data exposure, retention risk, and compliance burden, and attackers often target logs because they contain high-value context.
What should be removed before logs are stored?
Start by treating logs as operational records, not a place to preserve everything an application can see. The main filter is simple: keep the fields needed for troubleshooting, alerting, auditability, and forensic reconstruction, then remove or transform anything that can authenticate, identify, or expose a person or account.
That usually means excluding secrets, full tokens, passwords, session identifiers, payment data, full personal data, and high-risk payloads. Where you still need context, preserve structure or last-four style fragments instead of the full value so analysts can correlate events without increasing exposure.
How do redaction, masking, and minimisation work together?
These controls solve different parts of the same problem. Minimisation prevents unnecessary data from entering the log stream, masking preserves usefulness by partially obscuring sensitive values, and redaction removes the value entirely when even partial disclosure is too risky. Used together, they reduce the chance that logs become a shadow copy of production data.
Redaction should happen as early as practical, ideally at the source or in the log pipeline before data is widely forwarded or indexed. Masking is most useful when investigators need pattern recognition, such as matching a user, request, or transaction across events without exposing the underlying secret or personal attribute. For a structured logging baseline, see the Log Management and Retention Guide.
Why is access control part of log-data risk reduction?
Even well-trimmed logs can become sensitive once they are centralised, searchable, and retained for long periods. Access control matters because logs often reveal session context, network paths, error traces, and account activity that can help an attacker move laterally or abuse a legitimate workflow if the log store is too open.
Log platforms should follow least privilege, with separate rights for collection, search, export, and administration. Limit who can read raw events, who can query across tenants or environments, and who can change retention, parsing, or forwarding rules. Log integrity controls matter as well, because tampered logs are almost as harmful as missing logs when you need to investigate.
Risk and Threat Considerations
Excessive logging turns a monitoring asset into a data exposure problem. The more fields and payloads you record, the more likely logs will contain secrets, regulated personal data, or operational clues that increase breach impact and retention burden.
Failure mechanism: Sensitive values are copied into multiple downstream systems, then retained longer and exposed to more users, more backups, and more search paths than the source application itself.
Impact: A single compromised log store can expose account access material, personal data, and incident context at scale, while also making compliance cleanup and breach scoping much harder.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | Log minimisation depends on limiting recorded audit fields. |
| AU-9 — Protection of Audit Information | Log stores need protection because they contain sensitive operational data. | |
| AC-6 — Least Privilege | Reducing who can query logs limits exposure of sensitive log content. | |
| Recommendation — Record only audit data needed for traceability and response. Restrict access and protect audit logs from unauthorised reading or alteration. Apply least privilege to log collection, search, export, and administration. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | This subject is directly about controlling what gets logged and how. |
| A.8.16 — Monitoring activities | Safe logging supports detection without over-collecting data. | |
| Recommendation — Define logging rules that exclude sensitive fields and preserve necessary evidence. Tune monitoring to capture security-relevant events without unnecessary payloads. | ||
Practitioner Guidance
What to verify: Test logs for the worst-case field set, not just the intended schema. Confirm that authentication material, bearer tokens, full card data, and free-text payloads cannot appear through errors, debug mode, exception dumps, or request echoing.
What good looks like: Analysts can still reconstruct who did what, when, and from where, but the stored event data is stripped of high-risk content and protected by tight read permissions. If that balance is not possible, the logging design should be changed rather than accepting broad capture as the default.
Practitioner takeaway: The best mitigation is to prevent sensitive data from entering logs in the first place, because once it is indexed, replicated, and retained, every later control has to work harder to contain the exposure.