A log sink is the destination where log data is sent, such as a file, service, analytics platform, or cloud logging endpoint. Sink choice matters because insecure transports, public storage, or weak permissions can turn otherwise useful logs into a durable source of data exposure.
Expanded Definition
A log sink is the final receiver for log records, but in security operations it is more than a simple endpoint. It can be a local file, a syslog receiver, a SIEM, a cloud-native logging service, an analytics pipeline, or a managed storage bucket. The important distinction is that the sink determines how logs are protected after collection, how long they remain available, who can query them, and whether the data can be tampered with or exfiltrated. In practice, log sinks sit at the intersection of observability, evidence retention, and access control, so their security properties matter as much as the logs themselves.
Guidance varies by platform, but the core principle is consistent: logs should be sent to a sink that preserves integrity, limits disclosure, and supports retention requirements. NIST control families for audit and monitoring, especially NIST SP 800-53 Rev 5 Security and Privacy Controls, reinforce that logging is only useful when it is protected throughout collection, transport, and storage. The term is often confused with a logging source, but a source generates events while a sink receives and stores them.
The most common misapplication is treating a writable storage location as a harmless sink, which occurs when teams forward sensitive logs into a bucket, share, or endpoint without encryption, retention limits, or access restrictions.
Examples and Use Cases
Implementing log sinks rigorously often introduces operational friction, because stronger access controls and immutable storage can make incident response and troubleshooting less convenient in the short term.
- Application logs are sent to a central SIEM so analysts can correlate authentication failures, privilege changes, and suspicious API calls across systems.
- Cloud audit events are delivered to a dedicated logging account or locked storage bucket, reducing the risk that a compromised workload can alter evidence.
- Security tooling forwards alerts and telemetry to a managed endpoint that supports retention, search, and chain-of-custody expectations.
- Container and orchestration logs are written to a service-side sink rather than node-local files, which helps preserve records when workloads are ephemeral.
- High-value systems use separate sinks for operational logs and security logs so administrators can tune access, retention, and review workflows independently.
For organisations handling identity-related events, the sink choice becomes especially important when logs include authentication traces, session metadata, or NHI activity. If those records are routed into a poorly governed destination, the log sink itself can become a concentration point for secrets exposure or privacy risk. That is why logging design is often discussed alongside storage controls and transport protections in frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls.
Why It Matters for Security Teams
Security teams rely on log sinks to preserve evidence, detect abuse, and support forensics, but a poorly designed sink can undermine all three. If the destination is publicly reachable, over-permissioned, or lacking integrity protections, attackers may delete traces, poison records, or harvest sensitive data from the logs themselves. That risk is particularly acute for identity and agentic AI environments, where logs may contain tokens, service account activity, tool-use events, or authorization decisions that reveal how systems behave.
From a governance perspective, the sink is part of the control surface, not just a storage detail. Teams need to decide whether logs land in a segregated account, whether transport is encrypted, whether retention is tamper-resistant, and whether access is limited to a small review group. Those decisions affect incident response readiness, regulatory defensibility, and the quality of investigations. Organisations typically encounter the full cost of a weak log sink only after an intrusion or compliance review, at which point the lack of trustworthy log data becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.PT | Log sinks support protective technologies for secure logging and event handling. |
| NIST SP 800-53 Rev 5 | AU-9 | AU-9 covers protection of audit information, including where logs are stored. |
| ISO/IEC 27001:2022 | A.8.15 | ISO logging controls require event logs to be protected and retained securely. |
| NIST SP 800-63 | Identity event logs often include authenticator and session data relevant to assurance. | |
| OWASP Non-Human Identity Top 10 | NHI telemetry can expose secrets or token use when logs reach weak destinations. |
Store NHI logs in hardened sinks and exclude secrets from log payloads wherever possible.
Related resources from NHI Mgmt Group
- How should security teams handle AI agents that need to log into SaaS applications?
- What breaks when hospitals do not log access to electronic patient data?
- How should security teams log privileged SSH access from bastion hosts?
- How should security teams log PostgreSQL activity without hurting performance?
