Security Logging Standard Template (OMB M-26-14, NIST AU)

Security Logging Standard: [Organisation name]

Organisation-wide standard for security event logging: what every system must log, in which format, how logs reach the central platform, how they are protected, how long they stay searchable and retrievable, how personal data in logs is minimised, and how coverage and detection value are measured. Informed by the joint guide Best Practices for Event Logging and Threat Detection (ASD's ACSC with CISA, FBI, NSA and international partners, August 2024), the NIST SP 800-53 Rev. 5 Audit and Accountability (AU) control family (Release 5.2.0, August 2025), and, for United States federal agencies, OMB Memorandum M-26-14 (22 May 2026), which rescinded M-21-31. NIST SP 800-92 Rev. 1 is cited only as an initial public draft. Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company (Example).

Document control

Approvals

Revision history

Contents

1. Purpose
2. Scope and applicability
3. Roles and responsibilities
4. Policy statements
5. Required log sources by tier
6. Required fields, format and time synchronisation
7. Centralisation and SIEM
8. Integrity, protection and access control
9. Retention
10. Privacy and data minimisation
11. Coverage measurement and metrics
12. Detection use cases
13. Onboarding a log source
14. Exceptions and risk acceptance
15. Compliance, review and related documents
16. Glossary and references

1. Purpose

This standard sets the minimum security logging that every system owned or operated by [Organisation name], or operated by a third party on its behalf, must provide. It exists so that the security operations centre (SOC) can:

1. Detect malicious activity promptly, including techniques that use legitimate administrative tools and valid accounts.
2. Investigate a suspected compromise and establish its scope, entry point, lateral movement, affected data and timeline.
3. Support containment, recovery and lessons learned, and provide evidence to regulators, customers, insurers and law enforcement when required.
4. Demonstrate that controls operate, for audits and customer assurance.

The standard balances detection value against cost and privacy. Collecting everything is neither affordable nor lawful; collecting too little leaves incidents unexplained. Each required source in section 5 is justified by a detection or investigation need in section 12.

2. Scope and applicability

In scope:

• Production, staging and corporate environments, on premises and in every cloud account, subscription or project.
• Identity providers, endpoints, servers, containers and Kubernetes clusters, network and edge devices, databases and data platforms.
• Software-as-a-Service (SaaS) applications that hold company or customer data, including collaboration, source control and CI/CD services.
• Operational technology (OT) and Internet of Things (IoT) devices that are part of a company information system.
• Systems operated by suppliers on the organisation's behalf, through contract clauses (section 4, LOG-POL-012).

Out of scope:

• Application performance telemetry used only for reliability (see Observability Specification (ops/observability-spec)).
• Content of customer documents and messages. Logs record events about data, never the data itself (section 10).
• [Example: Personal devices not enrolled in mobile device management.]

Where this standard conflicts with a law, regulation or contract, the stricter applicable requirement wins and the conflict is recorded as an exception (section 14) or a change request to this standard.

3. Roles and responsibilities

RACI (R responsible, A accountable, C consulted, I informed):

4. Policy statements

Control references point to NIST SP 800-53 Rev. 5 identifiers. Map them to your own control framework in your statement of applicability.

5. Required log sources by tier

5.1 System tiers

The prioritisation follows the joint guide's logic: favour sources most likely to be targeted and most damaging if compromised, and sources that reveal living off the land (LOTL) activity.

5.2 Source catalogue

Rules for the catalogue:

• Cloud control plane: log all control plane operations, including API calls and console sign-ins, with read and write activity for Tier 1 resources. Enable organisation-level trails so that new accounts inherit logging.
• SaaS: confirm under the shared responsibility model which audit events the provider exposes, at which licence tier, and for how long the provider keeps them. Pull them into the central platform; do not rely on the provider console as the retention store.
• OT: many OT devices cannot produce detailed logs, and heavy logging can affect constrained controllers. Use passive network sensors and historian data instead, and agree logging changes with the OT engineering owner.
• Mobile: log device posture, sign-ins and mobile device management events. Get legal advice before logging anything from personally owned devices, such as location.

5.3 Event categories that every Tier 1 system must cover

The following categories are the minimum investigative baseline and a sound baseline for any organisation. They cover the data-collection activities listed for US federal agencies in OMB M-26-14 Appendix B item 5 (items a to f, i and j); the detection activities in the same list (hunting for known indicators of compromise, anomalous activity and automated alerts, items g, h and k) are covered by section 12:

1. Which identity performed each operation, including service accounts.
2. Source and destination network address, protocol, port and session attributes.
3. Access to, modification of and deletion of objects and data.
4. Changes to privilege levels and role assignments.
5. Addition, removal and modification of infrastructure, endpoints and devices.
6. Alerts from security tooling such as EDR, intrusion detection and gateways.
7. Data that lets responders estimate the quantity and type of data affected, and the attack vector, including initial access and lateral movement.

6. Required fields, format and time synchronisation

6.1 Required fields

6.2 Format

• Use structured logs (JSON or key-value pairs) with a consistent schema per log type. Normalise at ingestion to the organisation's schema [Example: Elastic Common Schema or OCSF] and keep the original event.
• Version parsers. SaaS and vendor formats change without notice: alert on parser failure rates, not only on volume.
• Where an event also flows into the operational telemetry pipeline, align attribute names with the OpenTelemetry semantic conventions adopted in the Observability Specification (ops/observability-spec).

6.3 Time synchronisation

• All systems MUST synchronise to the designated internal time sources using NTP or an equivalent protocol; Tier 1 systems SHOULD use at least two sources so that the loss of one does not skew time (NIST SP 800-53 Rev. 5 SC-45, SC-45(1) and SC-45(2)).
• Record events in UTC. Convert to local time only in presentation.
• OT environments take time from the IT environment, never the reverse.
• Alert when clock drift on a Tier 1 host exceeds [Example: 1 second].
• Log device boots, restarts and time changes, as they explain gaps.

7. Centralisation and SIEM

Requirements:

1. The SOC MUST be able to query every Tier 1 source from one place within the latency target, either because the logs are stored centrally or because the central platform has federated query access to them.
2. Collectors MUST buffer locally during outages for at least [Example: 24 hours] and replay in order.
3. The pipeline MUST tag each event with source_system and source_tier, apply redaction rules (section 10) before the hot tier, and write the raw event to the archive.
4. Enrichment SHOULD add asset owner, environment, geolocation of public IPs and identity attributes, so that triage does not require lookups.
5. Every source MUST have an expected volume baseline; a drop of more than [Example: 50 percent] against the same hour last week, or silence for more than [Example: 30 minutes] on Tier 1, raises an ingestion alert.
6. The platform's own audit logs (queries, rule changes, user changes, retention changes) are a Tier 1 source.

8. Integrity, protection and access control

9. Retention

9.1 Definitions

• Searchable (hot): data that detections and analysts can query immediately, without preparation.
• Retrievable (cold): data that can be used after one or more preparation steps, such as restoring from archive or rehydrating into the search platform. The standard sets a maximum retrieval time.

These definitions follow the meaning used in OMB M-26-14.

9.2 Retention schedule

Set the values from a risk assessment. The joint guide notes that default retention periods are often too short and that intrusions can go undetected for long periods; logs that confirm an intrusion and its impact deserve the longest retention. Check storage allocations at the same time as retention periods, because systems that overwrite logs when storage fills silently shorten retention. US federal agencies: set no log class below 6 months searchable and 12 months retrievable (9.3); several Example rows above are below that baseline.

9.3 Benchmark for US federal agencies (OMB M-26-14)

OMB M-26-14 (22 May 2026) rescinded M-21-31 with immediate effect and replaced its event logging tiers with a baseline and a maturity model. As published, Appendix B requires retained logs to be actively searchable for at least 6 months after creation and retrievable for a year after creation, without relieving agencies of records schedule obligations. Its Appendix C maturity model rates data retention, collection coverage, collection operations, inventory visibility and log management, with overall maturity set by the lowest-scoring element. CISA released the Logging Reference Architecture (LRA) required by the memorandum on 20 August 2026 (cisa.gov/Logging), together with an agency logging plan template; the memorandum's deadlines for agency logging plans and maturity levels run from the LRA release. Check the current LRA version before relying on it. The memorandum applies to US federal agencies as defined in 44 U.S.C. 3502, excluding national security systems and certain Department of Defense and Intelligence Community systems; other organisations can use it as a benchmark. Check the current text at whitehouse.gov before relying on it.

9.4 Legal hold and disposal

• Legal counsel places holds by case ID; the platform MUST suspend deletion for matching data and record the hold.
• At the end of retention, data is deleted automatically and the deletion job is logged. Manual deletion follows LOG-POL-004.
• Records schedules and privacy law can require shorter or longer periods than this standard. Record the governing rule per log class.

10. Privacy and data minimisation

1. Necessity: each personal data field in section 6.1 has a documented security purpose. Do not log fields "in case they are useful".
2. Never log: passwords, MFA secrets, session cookies, bearer tokens, API keys, private keys, full payment card numbers, document or message content, health data.
3. Redact or tokenise at the pipeline: query strings with tokens, authorisation headers, email bodies, form fields. Keep a keyed hash where correlation is needed (for example HMAC-SHA-256 with a key held in the key management service, separate from the log platform administrators), and rotate the key per retention period. A plain or fixed-salt hash of an email address or IP address can be reversed by brute force and is not real pseudonymisation.
4. Pseudonymise where analysts do not need the identity for triage, with re-identification restricted to investigators.
5. Purpose limitation: security logs MUST NOT be used for performance management of employees except through an approved HR investigation process involving legal counsel.
6. Transparency: describe security logging in employee and customer privacy notices, and record processing in the records of processing (compliance/gdpr-ropa where GDPR applies).
7. Data residency: where privacy or sovereignty law applies, record the storage region for each log class and assess transfers.
8. Lawful basis and storage limitation: record the lawful basis for each log class (for example legitimate interests in network and information security, GDPR Recital 49) and tie retention to the storage limitation principle through section 9. Check works council or employee consultation duties before monitoring employee activity in jurisdictions that require them.
9. Review: the DPO reviews new sources carrying personal data and the redaction rule set at least annually.

Assess high-risk processing, such as user behaviour analytics over employee activity, with a DPIA (compliance/dpia).

11. Coverage measurement and metrics

Worked example (Example): Corvid Commerce has 120 Tier 1 systems in its inventory. 111 send every required Tier 1 source. LOG-MET-001 = 111 / 120 x 100 = 92.5 percent, below the 95 percent target. The 9 gaps are 5 SaaS tools without audit API licences and 4 legacy virtual machines without EDR. Each gap gets an owner and a remediation date, or an exception (section 14).

Gap remediation SLA (Example): Tier 1 gap fixed within 30 days, Tier 2 within 60 days, Tier 3 within 90 days, measured from detection of the gap.

12. Detection use cases

Technique IDs were checked against MITRE ATT&CK Enterprise v20 and ATT&CK for ICS (October 2026). ATT&CK v19 split Defense Evasion into Stealth (TA0005) and Defense Impairment (TA0112), and v20 keeps that split: the former Impair Defenses sub-techniques now sit under T1685 Disable or Modify Tools, so disabling a cloud trail is T1685.002 and clearing Windows event logs is T1685.005. The same IDs are used in the SOC Playbook (security/soc-playbook) and the Detection Rule Specification (security/detection-rule-spec). Check every ID against the current release before reuse, because techniques are renamed, merged and revoked between releases. Response procedures for these use cases live in SOC playbooks; proactive searches over the same data live in the Threat Hunting Plan (security/threat-hunting-plan).

Traceability (Example): policy LOG-POL-009 requires a use case per Tier 1 source; source SRC-CLD-001 maps to DUC-003 and DUC-004; DUC-003 is implemented as rule DET-CLD-003 in the detection rule repository; its response is playbook PB-CLD-002 (trigger TRG-04 in the SOC Playbook); its coverage counts toward LOG-MET-007.

13. Onboarding a log source

1. Classify: the system owner assigns the tier (5.1) and lists the applicable source IDs (5.2). Verify: tier recorded in the asset inventory.
2. Privacy check: the system owner lists personal data fields; the DPO approves or requests redaction. Verify: approval recorded on the onboarding ticket.
3. Enable logging: configure required events, time sync and forwarding as code. Verify: configuration merged and deployed.
4. Parse and normalise: platform engineering adds or reuses a parser and maps fields to the schema. Verify: parse success above 99 percent on a test sample.
5. Baseline volume and health: record the expected volume and set silence and drop alerts. Verify: a test silence triggers the alert.
6. Detections: detection engineering links at least one use case for Tier 1. Verify: rule fires on a test event.
7. Retention: confirm the hot and archive tiers apply the right log class. Verify: retention settings exported and attached.
8. Sign-off: SecOps lead approves. Verify: source added to the catalogue with owner and date.

Rollback: if forwarding harms system performance, reduce verbosity to the Tier minimum rather than disabling logging, inform the SOC, and open an exception if the minimum cannot be met.

Decommissioning: keep the logs for their retention period after the system is retired; remove silence alerts only after confirming the decommission in the inventory.

14. Exceptions and risk acceptance

Example (Example): LOG-EXC-004, LOG-POL-001, support desk SaaS (Tier 2). The current plan exposes admin audit events only through the web console with 90 days of history. Risk: limited investigation of support agent account misuse beyond 90 days. Compensating control: weekly export of audit events to the archive and alerting on admin role changes through the identity provider. Approved by [@secops-lead], expires YYYY-MM-DD, pending a plan upgrade.

15. Compliance, review and related documents

Compliance measurement: the SecOps lead reports the metrics in section 11 monthly to the security steering committee. Internal audit tests a sample of systems against sections 5, 6, 8 and 9 at least annually. Non-compliance without an approved exception is recorded as a finding with an owner and due date; repeated Tier 1 gaps escalate to the CISO.

Review cycle: review at least annually, after any major incident where missing logs hindered the investigation, after a SIEM or pipeline change, and when relevant law or guidance changes.

Related documents:

16. Glossary and references

16.1 Glossary

16.2 References

Standard and licence note

Based on OMB Memorandum M-26-14 (22 May 2026) and NIST SP 800-53 Rev. 5 (Release 5.2.0), works of the United States Government not subject to copyright in the United States, and informed by the joint guide Best Practices for Event Logging and Threat Detection (August 2024), © Commonwealth of Australia 2024, published by ASD's ACSC with international partners under the Creative Commons Attribution 4.0 International licence (https://creativecommons.org/licenses/by/4.0/); this template paraphrases its recommendations in original words and is not endorsed by any of the authoring agencies. NIST SP 800-92 Rev. 1 is cited as an initial public draft only. MITRE ATT&CK technique identifiers and names are cited as references: © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Product and schema names (Elastic Common Schema, OCSF, AWS) are trademarks of their owners; this template is not affiliated with or endorsed by them. Check the current official versions of every source before relying on this standard, as revisions may have been published. Original text written for this collection. Template licence: MIT.