# Audit Logging Standard

**Template version:** 1.0.0 · **Edition:** Ready to adopt · **NIST basis:** SP 800-53 Rev. 5, release 5.2.0

*Tailor this template before adoption; it is not legal advice.* Latest version: <https://kston83.github.io/nist-guide/templates/standards/audit-logging-standard/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

| Owner | Approved by | Version | Effective date |
| --- | --- | --- | --- |
| [Chief Information Security Officer] | [Fill in: name and title] | [Fill in: version] | [Fill in: date] |

## 1. Purpose and scope

This standard sets the minimum requirements for generating, collecting, protecting and keeping the audit records of the systems of [Organization name]. It applies to every system in the system inventory and every component in each system's component inventory: servers, workstations, network and security devices, databases, applications, identity services, and cloud services, including systems that providers operate for the organization.

Part A applies across the organization. Each system completes Part B.

## 2. Roles

| Role | Responsibilities |
| --- | --- |
| [Chief Information Security Officer] | Owns this standard and the event list; coordinates the event list with the teams that use audit information; approves exceptions |
| [Security operations team] | Runs the central log platform; onboards log sources; monitors that every source is reporting; manages logging functions and the platform's access; reviews the logs under the log review procedure |
| [System owner] | Completes Part B; makes every component log the events in section 3 with the content in section 4 and send them to the central log platform; sizes local log storage; responds to logging failures |
| System administrators and developers | Configure logging on components and in applications as this standard and the baseline configuration standard set |
| [Senior privacy official] | Reviews the personal information written to audit records, with the system owner, and the event list's effect on privacy |
| [Fill in: records officer and legal counsel] | Set retention under the records retention schedule, and issue and release legal holds on audit records |

## Part A. Organization-wide requirements

### 3. Event types

- Each system owner shall identify, in Part B, the event types the system's components are capable of logging in support of the audit function, covering at least [Fill in: the event types that the system is capable of logging in support of the audit function. Typical: logons and logoffs, account and privilege changes, use of privileged functions, access to security-relevant files, configuration changes, and security tool events]. (AU-2a)
- The [Chief Information Security Officer] shall coordinate the event list with the [Security operations team], the [Incident response team], the [Senior privacy official], legal counsel and other organizational entities that need audit-related information, before it is approved and at each review. (AU-2b)
- Each system shall log [Fill in: event types (subset of the event types defined in AU-2a.) along with the frequency of (or situation requiring) logging for each identified event type. Typical: the event types listed in the audit logging standard, each logged whenever it occurs]; the table below is the minimum list, and Part B adds the system's own event types. (AU-2c)
- The rationale column of the table records why each event type is logged, and each system owner shall record in Part B why the system's selection, with its additions and any event types its components cannot log, is adequate to support after-the-fact investigation of incidents. (AU-2d)
- The [Chief Information Security Officer] shall review and update the event list [Fill in: the frequency of event types selected for logging are reviewed and updated. Typical: annually and after a significant incident or system change], and each system owner shall review Part B at the same time. (AU-2e)
- Event logging shall cover every protocol and access path the system supports, including local consoles, remote administration, web sign-in and programming interfaces. (AU-2c)

| # | Category | Event types logged | Logged | Related controls | Why it is logged (AU-2d) |
| --- | --- | --- | --- | --- | --- |
| 1 | Authentication | Successful and failed logons and logoffs by people and services at every access path; multi-factor authentication failures; account lockouts and unlocks | Every occurrence | AC-7, IA-2 | Shows who used the system and when; failures reveal password guessing and the use of stolen credentials |
| 2 | Account management | Account creation, modification, enabling, disabling and removal; password and authenticator changes and resets | Every occurrence | AC-2(4) | Unauthorized accounts and resets are a common way to gain and keep access |
| 3 | Privileges | Changes to group, role and privilege assignments, and to security or privacy attributes; use of privileged functions, including elevation such as "run as" | Every occurrence | AC-6(9) | Privilege misuse and escalation are the steps that turn a foothold into control of the system |
| 4 | Remote access | Start and end of remote access sessions, with the method and source address | Every occurrence | AC-17(1) | Most intrusions arrive remotely; sessions tie activity to an entry point |
| 5 | Security-relevant objects | Access, and failed access, to security-relevant files, audit records, key and secrets stores, and access control settings | Every occurrence | AU-9 | Shows tampering with the controls and the evidence itself |
| 6 | Configuration and software | Changes to configuration and security settings; installation and removal of software; new or changed services and scheduled tasks | Every occurrence | CM-3f | Unapproved changes are both an attack technique and a control failure; records are compared with change requests |
| 7 | Logging and security tools | Logging started, stopped, changed or cleared; log forwarding failures; security tools stopped or disabled; malicious code detections and security tool alerts | Every occurrence | AU-5, SI-3 | Attackers disable logging and security tools first; tool events are the earliest signs of compromise |
| 8 | System events | Start-up and shutdown; services started and stopped; system time changes; components added or removed | Every occurrence | AU-8, CM-8 | Explains gaps and order in the record, and shows unauthorized components |
| 9 | Network | Connections allowed and denied at managed interfaces; domain name queries; network flow records from boundary components | Every occurrence, or continuously for flow records | AC-4, SC-7 | Traces lateral movement and data leaving the system, and ties addresses to activity |
| 10 | Sensitive information | Access to, export of, and deletion of sensitive information, and bulk downloads, with the query parameters where the privacy impact assessment allows | Every occurrence | AC-3 | Shows what information was affected during an incident, and by whom |
| 11 | Applications | Authorization failures; administrative actions in the application; input validation failures and security-relevant errors | Every occurrence | AC-3, SI-10 | Application attacks and misuse leave no trace in operating system logs |
| 12 | Cloud management | Management console and programming interface calls that create, change or delete resources; identity and access management changes | Every occurrence | AC-2(4), CM-3f | Control plane changes can alter every workload in the account at once |

### 4. Content of audit records

- Each audit record shall contain the fields in the table below, establishing what type of event occurred, when and where it occurred, its source, its outcome, and the identity of any individuals, subjects or objects associated with it. (AU-3)
- Each system shall also generate audit records that contain [Fill in: additional information to be included in audit records. Typical: session and request identifiers, source and destination addresses, and the full command line for privileged commands]. (AU-3(1))
- Applications written by or for the organization shall write structured records, such as JSON, using the field names in the table, and the central log platform shall parse every log source into the same field names. (AU-3)
- Actions taken through a shared, group or service account shall be traceable to the individual or process that took them, through the session, the privileged access tool or the request that started them. (AU-3)
- Audit records shall not contain passwords, authenticators, session tokens, cryptographic keys or other secrets; applications shall mask them before the record is written. (IA-5g)

| Field | AU-3 item | Examples |
| --- | --- | --- |
| Event type | What type of event (a) | Event name or identifier, such as "logon failed" or "user added to group" |
| Time stamp | When it occurred (b) | Date and time in Coordinated Universal Time (UTC), or with its offset from UTC, to the granularity in section 7 |
| Location | Where it occurred (c) | Host name, component, application, cloud account and region |
| Source | Source of the event (d) | Source address, device, process or service |
| Outcome | Outcome of the event (e) | Success or failure, with the reason or error code |
| Identity | Who or what was involved (f) | User or service account, the individual behind a shared account, and the files, records or resources acted on |

### 5. Personal information in audit records

This section applies to systems that process personally identifiable information.

- Personally identifiable information contained in audit records shall be limited to the following elements identified in the privacy risk assessment: [Fill in: elements identified in the privacy risk assessment. Typical: the account identifier, the source address and device, and the identifiers of records accessed, not their contents]. (AU-3(3))
- The [System owner] shall list in Part B the personally identifiable information elements each log source writes, and record them in the system's privacy impact assessment. (AU-3(3))
- Request bodies, form inputs, query strings and other content that may hold personal information shall be masked, truncated or left out of audit records unless the privacy impact assessment lists them as needed. (AU-3(3))
- Access to audit records that contain personally identifiable information shall be limited to the roles that need it for review, investigation and audit. (AU-9)

### 6. Generation and collection

- [Fill in: system components that provide an audit record generation capability for the events types. Typical: all servers, network devices, security tools, databases and applications in the system boundary] shall provide an audit record generation capability for the event types in section 3. (AU-12a)
- Only [Fill in: personnel or roles allowed to select the event types that are to be logged by specific components of the system. Typical: the system administrators, with the security operations team approving changes] shall select the event types that specific components of the system log. (AU-12b)
- Each system shall generate audit records for the event types in section 3 and Part B, with the content in section 4. (AU-12c)
- Each component type's logging settings shall be part of its secure configuration in the [baseline configuration standard](https://kston83.github.io/nist-guide/templates/standards/baseline-configuration-standard/), and checked by its configuration scans. (CM-6)
- A new component shall have logging configured, and its records confirmed arriving on the central log platform, before it goes into production. (AU-12a)
- Each component shall send its audit records to the central log platform, as section 4 of the system monitoring standard sets, over a channel that protects them as the [encryption and key management standard](https://kston83.github.io/nist-guide/templates/standards/encryption-and-key-management-standard/) requires. (AU-9)
- A component that cannot send its records to the platform shall keep them locally under this standard, and Part B shall record it as an exception with how its records are reviewed. (AU-12a)

### 7. Time stamps

- Each system shall use internal system clocks to generate time stamps for audit records. (AU-8a)
- Audit record time stamps shall meet a granularity of [Fill in: granularity of time measurement for audit record timestamps. Typical: one second or finer] and use Coordinated Universal Time, a fixed offset from it, or include the local offset in the time stamp. (AU-8b)
- Every component shall synchronize its clock with [Fill in: the organization's authoritative time source, for example its network time servers], so that records from different components can be put in order. (AU-8)

### 8. Storage capacity and logging failures

- Each system owner, with the [Security operations team], shall allocate audit log storage capacity to accommodate [Fill in: audit log retention requirements. Typical: the retention period set under AU-11, with room for a year of growth], on each component and on the central log platform. (AU-4)
- Components shall buffer audit records locally for at least [Fill in: for example 72 hours] when they cannot reach the central log platform, and send them when the connection returns. (AU-4)
- The [Security operations team] shall check storage use on the central log platform [Fill in: for example monthly] and plan capacity before new log sources are added. (AU-4)
- Each system shall alert [Fill in: personnel or roles receiving audit logging process failure alerts. Typical: the system administrators and the security operations team] within [Fill in: time period for personnel or roles receiving audit logging process failure alerts. Typical: 1 hour] of an audit logging process failure, including software and hardware errors, failures of the mechanisms that capture records, a log source that stops reporting, and storage reaching capacity. (AU-5a)
- When an audit logging process fails, the [System owner] shall [Fill in: additional actions to be taken in the event of an audit logging process failure. Typical: restore logging and record the gap in the audit trail; for high-impact systems, stop processing that cannot be logged]. (AU-5b)
- Each failure shall be recorded with its start and end, the components affected, the cause, and the gap left in the audit trail. (AU-5b)

### 9. Protection of audit information

- Audit information and audit logging tools shall be protected from unauthorized access, modification and deletion: records on the central log platform shall be stored so that no user, including the platform's administrators, can change them, and deleted only by the retention process in section 10. (AU-9a)
- The central log platform shall alert [Fill in: personnel or roles to be alerted upon detection of unauthorized access, modification, or deletion of audit information. Typical: the security operations team and the system owner] when unauthorized access, modification or deletion of audit information is detected. (AU-9b)
- Access to management of audit logging functionality shall be authorized only for [Fill in: a subset of privileged users or roles authorized to access management of audit logging functionality. Typical: the security operations administrators, who do not administer the systems being audited]. (AU-9(4))
- Administrators of a system shall not be able to delete or change its audit records on the central log platform, or turn off forwarding without the change being logged and alerted. (AU-9(4))
- Read access to audit records shall be role-based, limited to those who review, investigate and audit, and itself logged. (AU-9a)
- Audit records shall be encrypted at rest, and backups and archives of them protected like the originals. (AU-9a)

### 10. Retention and disposal

- Audit records shall be retained for [Fill in: a time period to retain audit records that is consistent with the records retention policy. Typical: at least one year, or longer where the records retention schedule or a law requires it], to support after-the-fact investigation of incidents and to meet regulatory and organizational retention requirements. (AU-11)
- Audit records shall be kept [Fill in: for example 6 months] in a form that can be searched at once, and the rest of the retention period in a form that can be restored for search when needed, as the system monitoring standard sets. (AU-11)
- Audit records named in a legal hold, or needed for an investigation, a records request or a law enforcement action, shall be kept until [Fill in: legal counsel] releases them, even after the retention period ends. (AU-11)
- When audit records are moved to an archive, their integrity shall be verified, for example by comparing hashes of the original and the copy. (AU-9)
- At the end of the retention period, audit records shall be disposed of under the records retention schedule, and media holding them sanitized as the media protection policy requires. (AU-11)
- Restoring archived audit records for search shall be tested [Fill in: for example annually]. (AU-11)

### 11. Additional requirements for High systems

This section applies to High systems.

- The system shall provide a warning to [Fill in: personnel, roles, and/or locations to be warned when allocated audit log storage volume reaches a percentage of repository maximum audit log storage capacity. Typical: the system administrators and the security operations team] within [Fill in: time period for defined personnel, roles, and/or locations to be warned when allocated audit log storage volume reaches a percentage of repository maximum audit log storage capacity. Typical: 1 hour] when allocated audit log storage volume reaches [Fill in: percentage of repository maximum audit log storage capacity. Typical: 75 percent] of the repository's maximum audit log storage capacity. (AU-5(1))
- The system shall provide an alert within [Fill in: real-time period requiring alerts when audit failure events occur. Typical: 15 minutes] to [Fill in: personnel, roles, and/or locations to be alerted in real time when audit failure events occur. Typical: the security operations team] when the following audit failure events occur: [Fill in: audit logging failure events requiring real-time alerts. Typical: loss of log forwarding from any component, and failure of the central log repository]. (AU-5(2))
- Audit records shall be stored [Fill in: the frequency of storing audit records in a repository. Typical: in near real time] in a repository that is part of a physically different system or system component than the system or component being audited. (AU-9(2))
- Cryptographic mechanisms shall protect the integrity of audit information and audit tools, such as signed hashes of records and of the logging software. (AU-9(3))
- The system shall provide irrefutable evidence that an individual, or a process acting on behalf of an individual, has performed [Fill in: actions to be covered by non-repudiation. Typical: approving access and changes, signing records, and administering security settings], such as by digital signatures bound to the individual's credential. (AU-10)
- Audit records from [Fill in: system components from which audit records are to be compiled into a system-wide (logical or physical) audit trail. Typical: all components that generate audit records] shall be compiled into a system-wide audit trail that is time-correlated to within [Fill in: level of tolerance for the relationship between timestamps of individual records in the audit trail. Typical: one second]. (AU-12(1))
- The capability shall be provided for [Fill in: individuals or roles authorized to change the logging on system components. Typical: the security operations administrators] to change the logging to be performed on [Fill in: system components on which logging is to be performed. Typical: all components in the system boundary] based on [Fill in: selectable event criteria with which change logging is to be performed. Typical: the event types in the audit logging standard, and additional detail for a user or component under investigation] within [Fill in: time thresholds in which logging actions are to change. Typical: 1 hour]. (AU-12(3))

### 12. Testing and exceptions

- The [Security operations team] shall test logging when a component type is onboarded, and on a sample of components [Fill in: for example at least annually], by generating test events such as a failed logon, a privileged command and a configuration change, and confirming each reaches the central log platform with the content in section 4. (AU-12c)
- A system or component that cannot meet this standard shall have an exception approved by the [Chief Information Security Officer], naming the requirement not met, the reason, the compensating measures and an expiry date, and recorded in Part B section 17. (AU-12)
- Where an exception leaves a weakness in an authorized system, it shall be entered in the system's plan of action and milestones, and the authorizing official shall accept the remaining risk. (CA-5)

#### Federal systems

[OMB M-26-14](https://www.whitehouse.gov/wp-content/uploads/2026/05/M-26-14-Ensuring-Effective-and-Efficient-Agency-Logging-and-Network-Visibility-to-Defend-Against-Evolving-Cyber-Threats.pdf), Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats (May 22, 2026), rescinded OMB M-21-31. Each agency submits an Agency Logging Plan to OMB and CISA within 90 days of the publication of CISA's [Logging Reference Architecture](https://www.cisa.gov/resources-tools/resources/logging-reference-architecture), which CISA published on August 20, 2026, and measures each system against the memo's logging maturity model (Appendix C). Appendix B sets the minimum logging baseline: retained logs actively searchable for at least 6 months after creation and retrievable for a year (item 1), without relieving agencies of records schedules; logs readily available to the agency's top-level security operations center (item 2); a consistently accurate time stamp, with network time synchronized through the Network Time Protocol or an equivalent to a traceable time source the agency designates, with sources traceable to the U.S. Naval Observatory or NIST encouraged (item 3); and logs that support a list of minimum activities (item 5). Item 4 says agencies should use Continuous Diagnostics and Mitigation, hardware asset management and software asset management data to check that log coverage takes in all information technology, including internet-of-things devices and operational technology. The memo does not apply to national security systems, or to the Department of Defense and Intelligence Community systems described in 44 U.S.C. § 3553(e). As of October 2026.

<!-- TODO(verify): NARA GRS 3.2 (Transmittal 33, January 2023) item 036, "Cybersecurity event logs", covers logs required by OMB M-21-31 and says destroy when 30 months old. M-26-14 rescinded M-21-31; confirm with NARA whether item 036 still applies and how before citing it here or in the AU-11 clause. -->

- Each system's audit records shall be actively searchable for at least 6 months after creation, and retrievable for at least one year after creation, as OMB M-26-14 Appendix B item 1 requires, and kept longer where a records schedule requires it. (AU-11)
- Each system's audit records shall be readily available to the agency's top-level security operations center, as Appendix B item 2 requires. (AU-6(3))
- Each component's clock shall be synchronized through the Network Time Protocol or an equivalent mechanism to the traceable time source the agency designates, as Appendix B item 3 requires. (AU-8)
- The event list in section 3 and each Part B shall support these activities, as Appendix B item 5 requires: determining the identity used to perform operations in applications and on systems; determining source and destination network addresses, including protocols, ports and session attributes; identifying data and resources accessed, modified or destroyed; identifying actions that change privilege levels; identifying changes to infrastructure, such as endpoints added, removed or modified; monitoring for suspicious activity security tooling identifies; monitoring, detecting and hunting for known indicators of compromise and for anomalous system or user activity; determining the quantity and types of data affected during an incident; determining the attack vectors, including initial access and lateral movement; and generating automated alerts for all of these. (AU-2c)
- Each system's logging shall be described in, and kept consistent with, the agency's Agency Logging Plan. (AU-2c)

## Part B. System logging record

Complete one Part B for each system, and reference it in the system security plan.

| System | System owner | Central log platform | Last reviewed |
| --- | --- | --- | --- |
| [Fill in: system name and identifier] | [Fill in: name and title] | [Fill in: for example the enterprise SIEM platform] | [Fill in: date] |

### 13. Log sources and event types

| Component or component type | Event types it can log | Event list rows logged (section 3) | Event types added for this system | Event types it can log but are not logged, and why | How records reach the platform |
| --- | --- | --- | --- | --- | --- |
| [Fill in: for example Windows servers] | [Fill in: for example the operating system security log] | [Fill in: for example 1 to 8] | [Fill in: event types, or none] | [Fill in: for example object access auditing on all files, enabled only during an investigation] | [Fill in: for example agent forwarding] |
| [Fill in: for example the application] | [Fill in: event types] | [Fill in: rows] | [Fill in: event types, or none] | [Fill in: event types and reason, or none] | [Fill in: method] |

### 14. Rationale

[Fill in: why the event types logged for this system are adequate to support after-the-fact investigation of incidents, including what the system's own additions cover and how gaps from section 13 are covered by other sources]

### 15. Personal information in audit records

Complete for a system that processes personally identifiable information.

| Log source | Personally identifiable information elements written | Why each is needed | Masking or omission applied | Privacy impact assessment reference |
| --- | --- | --- | --- | --- |
| [Fill in: log source] | [Fill in: for example account identifier, source address] | [Fill in: reason] | [Fill in: for example request bodies omitted] | [Fill in: section and date] |

### 16. Storage and retention

| Store | Location | Capacity allocated | Searchable for | Retained for | Protection |
| --- | --- | --- | --- | --- | --- |
| [Fill in: for example local buffer on each component] | [Fill in: location] | [Fill in: capacity] | [Fill in: period] | [Fill in: period] | [Fill in: for example local access restricted to administrators] |
| [Fill in: for example central log platform] | [Fill in: location] | [Fill in: capacity] | [Fill in: period] | [Fill in: period] | [Fill in: for example immutable storage, encrypted] |

### 17. Exceptions in effect

| Exception ID | Requirement not met | Components affected | Reason | Compensating measures | Approved by and date | Plan of action and milestones ID | Expiry |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [Fill in: ID] | [Fill in: section and requirement] | [Fill in: components] | [Fill in: reason] | [Fill in: measures] | [Fill in: name and date] | [Fill in: ID, or not a weakness] | [Fill in: date] |

## 18. Review

The [Chief Information Security Officer] reviews Part A [Fill in: the frequency of event types selected for logging are reviewed and updated. Typical: annually and after a significant incident or system change], and whenever the audit and accountability policy, the central log platform, or a federal logging requirement changes. Each system owner reviews Part B at the same time, and when the system's components or log sources change.

| Version | Date | Change | Approved by |
| --- | --- | --- | --- |
| [Fill in: version] | [Fill in: date] | [Fill in: summary of change] | [Fill in: name and title] |