NIST SP 800-92 Log Management Guide

Organisations collect more logs than ever, yet investigations still stall because the right events were never generated, were kept too briefly or cannot be trusted. NIST SP 800-92 is the long-standing US reference for planning security log management: what to log, how to move and store it, how long to keep it and who is responsible. The 2006 guide remains the final version, and a substantially rewritten Rev. 1 draft, published in 2023 as a planning playbook, is still marked as an initial public draft on the NIST site as of October 2026. This guide explains both versions, how they relate to current federal logging policy (OMB M-26-14, which rescinded M-21-31 in May 2026), and how to turn them into a log management plan you can evidence. It is written for security operations, platform and identity teams, and for the managers who must justify logging budgets.

Key takeaways

Two documents, one final. SP 800-92 (September 2006) is final; SP 800-92 Rev. 1 Cybersecurity Log Management Planning Guide (October 2023) is an initial public draft and should be cited as a draft.
Rev. 1 is a planning playbook, not a configuration guide. Its four plays are update inventories (INV), define the target state (TS), document gaps and root causes (GRC), and develop a plan to mitigate the gaps (PMG).
NIST does not set retention periods. Retention comes from your own requirements; for US federal agencies, M-26-14 now sets at least 6 months searchable and 1 year retrievable.
Identity events are the highest-value logs. Authentication, privilege changes and token use by people and non-human identities are what most investigations depend on.
Logs are an attack target. Protect integrity, synchronise time and alert on logging being disabled or cleared (ATT&CK T1685.001 and T1685.005).

What it is and who it applies to

NIST SP 800-92 Guide to Computer Security Log Management, by Karen Kent and Murugiah Souppaya, was finalised on 13 September 2006. Its CSRC page records no revision or withdrawal. In October 2023 NIST released SP 800-92 Rev. 1 as an initial public draft, by Karen Scarfone and Murugiah Souppaya, retitled Cybersecurity Log Management Planning Guide; comments closed on 29 November 2023. When this guide was checked (24 October 2026) the document history still listed only that draft, so treat Rev. 1 as direction of travel and check CSRC for a final version before quoting it as a requirement.

Both are voluntary guidance. They apply in practice wherever an organisation uses NIST as its baseline, including federal systems assessed against SP 800-53 Rev. 5 audit (AU) controls and contractors working to SP 800-171. US federal logging policy now sits in OMB M-26-14 Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats (22 May 2026), which states that M-21-31 is rescinded with immediate effect. M-26-14 does not reference SP 800-92.

Document	Status	Focus	Use it for
SP 800-92 (2006)	Final	Log management infrastructure, functions, policy and operational processes	Architecture concepts, function vocabulary, syslog security, roles
SP 800-92 Rev. 1 (2023)	Initial public draft	Planning playbook across the log lifecycle, including cloud	Structuring a log management improvement plan
OMB M-26-14 (2026)	In force for US federal agencies	Logging plans, retention, maturity levels 0 to 4, CISA logging reference architecture	Federal deadlines and retention minimums
Joint event logging best practices (ASD ACSC with CISA, FBI, NSA, NCSC-UK and others)	Guidance	Baseline event logging and threat detection	Prioritising log sources and detection

Structure and key requirements

SP 800-92 (2006): architecture and functions

The 2006 guide describes a three-tier log management infrastructure: log generation (hosts that produce logs), log analysis and storage (one or more log servers receiving data in real time, near real time or in batches) and log monitoring (consoles for review and reporting). Its executive summary makes four recommendations: establish log management policies and procedures, prioritise log management across the organisation, build and maintain a secure log management infrastructure sized for peak volumes, and give staff with log management duties adequate training, tools and support.

Function group	Functions named in SP 800-92	Modern equivalent
General	Parsing, event filtering, event aggregation	Collector or pipeline parsing, drop rules, deduplication
Storage	Rotation, archival, compression, reduction, conversion, normalisation, file integrity checking	Hot, warm and cold tiers, schema mapping, hashing or immutable storage
Analysis	Event correlation, log viewing, log reporting	SIEM correlation rules, search, dashboards
Disposal	Log clearing	Lifecycle deletion at the end of retention

The 2006 guide also flags that original syslog was not designed for security: UDP transport is unreliable, there is typically no access control, and there is no encryption or integrity protection. Today that maps to RFC 5424, which obsoletes the BSD format in RFC 3164, uses an RFC 3339-derived timestamp and requires implementations to support TLS transport (RFC 5425), which it recommends for deployments.

SP 800-92 Rev. 1 draft: the four plays

Play	Sub-plays	Output
INV: Update Logging-Related Inventories	INV-1 log source types; INV-2 logging infrastructure; INV-3 logging use cases; INV-4 requirements; INV-5 work roles	Current-state inventories
TS: Define Target State	TS-1 forecast future changes; TS-2 log generation; TS-3 log storage and transfer; TS-4 log access; TS-5 log disposal	Target state per lifecycle stage
GRC: Document Gaps and Their Root Causes	GRC-1 scope and plan the assessment; GRC-2 conduct the assessment and document findings	Gap register with root causes
PMG: Develop a Plan to Mitigate the Gaps	PMG-1 draft the plan; PMG-2 revise affected policies; PMG-3 address feedback	Approved plan and updated policies

Within the target-state play the draft covers clock synchronisation for all sources (TS-2.8), timestamp formats including time zones (TS-2.9), protecting log generation (TS-2.10), confidentiality, integrity and availability in storage and transfer (TS-3.5), when to move data to cold storage (TS-3.8), legal preservation (TS-4.2), monitoring access to logs (TS-4.4) and safeguarding disposal against unauthorised destruction (TS-5.3). It names source types (networks, software, cloud environments including virtualisation and containers, technology management tools, identity and authorisation technologies, and threat detection tools) and notes that a data lake can replace a single central log server. Appendix B crosswalks the plays to other NIST guidance.

Identity and NHI requirements

Rev. 1 names identity, authentication and authorisation technologies as a log source type in their own right, and M-26-14 lists user identity, privilege changes and access to or deletion of data among the records agencies must collect. For non-human identities this is often where coverage is weakest: service accounts, API keys and OAuth applications authenticate silently, and many SaaS platforms only expose token-level activity in higher licence tiers.

Source	Events to collect	Why it matters for NHIs
Windows and Active Directory	4624 and 4625 logons, 4648 explicit credentials, 4672 special privileges, 4720 account created, 4728 and 4732 group membership added, 4740 lockout, 4768 and 4769 Kerberos tickets, 4719 audit policy changed, 1102 audit log cleared	Service account logons outside their usual hosts, new privileges, Kerberos service ticket volume. See the Windows Event Log Guide.
Identity provider	Sign-ins (interactive and non-interactive), token issuance, consent grants, MFA changes, application credential added	New secrets on applications and unusual token use
Cloud control planes	API calls with caller identity, role assumption, key creation, logging configuration changes	Workload and access key misuse. See the Cloud Logging and Audit Trail Guide.
Secrets and PKI	Secret reads, rotations, certificate issuance and revocation	Who or what read a credential, and when
SaaS audit logs	Admin actions, API client activity, data export, mail item access	Integration accounts acting at scale

Microsoft notes that some of these Windows events, including 4624 and 4625, depend on audit policy settings and should be baselined before alerting. Every NHI event is only useful if it can be tied to an owner, so join logs to the identity inventory. See the Service Account Security Guide.

Implementation steps

The order below follows the Rev. 1 plays and adds the testing and rollback steps a live pipeline needs.

Inventory (INV): list log source types, the logging infrastructure (collectors, SIEM, data lake, cold storage, managed services), the use cases logs must support (detection, investigation, troubleshooting, compliance), the legal and contractual requirements, and the work roles responsible.
Set the target state (TS): per source, decide which events are generated, the format and timestamp standard, the transport (TLS syslog or agent), where each event lands, hot and cold retention periods, who may access logs and how disposal happens. Record federal or sector retention minimums here.
Assess gaps (GRC): compare current to target for a sample of systems, including at least one cloud tenant, one SaaS platform and the identity provider. Record root causes such as licence tier, missing audit policy or no owner.
Plan (PMG): prioritise gaps by risk and cost, update the logging policy (see the Logging and Monitoring Policy Template) and get sign-off from system owners.
Pilot changes: enable new audit settings on a pilot group first, measure volume and ingestion cost for a week, and confirm parsing before rolling wider. Keep the previous configuration exported as the rollback.
Protect the pipeline: synchronise all sources to an authoritative time source, send logs off-host quickly, write to storage that source administrators cannot delete, and hash or use immutable buckets for archives.
Monitor the monitor: alert when a source goes silent, when audit policy changes (event 4719) or when a log is cleared (event 1102), and on cloud logging being disabled.
Review annually: repeat TS-1 forecasting for new platforms, acquisitions and cloud migrations, and re-run the gap assessment.

Small and large organisations: a small organisation can often meet the intent with native cloud and identity provider logs routed to one managed SIEM or log service, and a written retention schedule. A large one needs a tiered architecture (a data lake or cold store for volume, a SIEM for detection), a data pipeline to filter and normalise before ingestion to control cost, and named owners per source. See the SIEM Guide and the Log Management and Retention Guide.

Evidence and assessment

Policy and plan: an approved log management policy, the inventories and the gap plan (the Rev. 1 outputs).
Source coverage report: assets in the inventory against assets actually sending logs. M-26-14 measures inventory visibility, with Level 1 requiring 70% of IT, OT and IoT assets in a central inventory and Level 4 requiring 95%.
Retention proof: a search returning events from the oldest required date, and restore tests from cold storage.
Integrity controls: configuration showing immutable or separate storage (SP 800-53 AU-9(2)), and access logs for the log platform itself.
Time synchronisation: configuration of time sources and a check of drift across a sample.

Metric	How to measure	Good sign
Log source coverage	Sources sending logs divided by sources in scope	Rising, with critical systems at 100%
Silent source detection time	Time from a source stopping to an alert	Hours, not weeks
Ingestion latency	Event time to searchable time	Minutes for detection sources
Retention compliance	Sources meeting their retention target	100% for regulated data
Identity event coverage	Identity providers, directories and SaaS tenants with authentication and admin logs collected	All, including non-interactive and service principal sign-ins
Clock drift	Maximum offset across sampled sources	Within your stated tolerance

Mapping to other frameworks

Log management area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Related threat (ATT&CK v20)
What to log and generating records	AU-2, AU-3, AU-12	PR.PS-04
Storage capacity and failure response	AU-4, AU-5	PR.PS-04	T1685.001 Disable or Modify Windows Event Log
Review, analysis and correlation	AU-6, AU-7, SI-4	DE.AE-03, DE.CM-01, DE.CM-03, DE.CM-09	T1078 Valid Accounts
Timestamps	AU-8
Protection of logs	AU-9, AU-9(2)	PR.PS-04	T1685.005 Clear Windows Event Logs
Retention	AU-11

CIS Controls v8.1 covers the same ground in Control 8 (Audit Log Management), and ISO/IEC 27001:2022 Annex A includes logging, monitoring activities and clock synchronisation controls. For the wider control families see the NIST SP 800-53 Guide and the NIST CSF 2.0 Guide.

Common pitfalls

Logging what is cheap, not what is needed: firewall and DNS volume fills the SIEM while identity provider, SaaS and cloud audit logs are missing. In the Microsoft Storm-0558 key breach, the US State Department spotted forged-token mail access through an alert on MailItemsAccessed, a log available to it because of its premium licence; organisations without that logging could not see the same activity.
Retention set by storage budget: intrusions often start weeks before detection, so short hot retention with no searchable archive leaves investigators blind.
Logs deletable by the people they record: administrators and service accounts with rights to clear local logs or disable cloud audit trails, without logs being shipped off-host first.
No time discipline: mixed time zones and unsynchronised clocks make correlation across sources unreliable.
Silent sources: a collector or agent fails and nobody notices for months.
Citing the draft as a requirement: auditors and contracts should reference the final 2006 publication, or name Rev. 1 explicitly as a draft.

Practitioner checklist

Record which SP 800-92 version you follow and recheck CSRC for a final Rev. 1 at each annual review.
Build the five Rev. 1 inventories: source types, infrastructure, use cases, requirements and work roles.
Write a retention schedule per source with hot and cold periods; for US federal systems apply M-26-14 minimums.
Collect identity provider, directory, cloud control plane and SaaS audit logs, including non-interactive and service principal sign-ins.
Synchronise all sources to an authoritative time source and standardise timestamp formats.
Ship logs off-host over TLS to storage that source administrators cannot alter or delete.
Alert on silent sources, audit policy changes and log clearing.
Test retention and restores at least annually, and report the six metrics above to management.

NIST SP 800-92 Log Management Guide: Planning, Collecting and Retaining Security Logs