# Log Review Procedure

**Template version:** 1.0.0 · **Edition:** Annotated (with guidance) · **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/procedures/log-review-procedure/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

> **Guidance:** The Audit and Accountability policy's AU-6 statements say audit records are reviewed, findings reported and the review stepped up when risk changes; this procedure says how, step by step, and section 3 is the list of inappropriate or unusual activity that the AU-6 clause's typical value points to. Its typical values are copied from the AU-6, AU-6(1), AU-6(5) and AU-7(1) clauses; keep them in step. Most AU-6 findings are about evidence, not effort: the review happened but left no record, so every step here names the record it leaves. Which events are logged, and how records are collected and kept, is in the [audit logging standard](https://kston83.github.io/nist-guide/templates/standards/audit-logging-standard/); detections, alert severities and triage times are in the [system monitoring standard](https://kston83.github.io/nist-guide/templates/standards/system-monitoring-standard/), which this procedure follows for alerts. The steps draw on [NIST SP 800-92](https://csrc.nist.gov/pubs/sp/800/92/final), Guide to Computer Security Log Management (September 2006), section 5.2 (analyzing log data) and section 5.3 (responding to identified events). One procedure can serve every system that sends its logs to the central log platform; a system whose logs stay local adds the system-level review in 5.3.

| 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 procedure carries out the audit record review, analysis and reporting requirements of the [Organization name] Audit and Accountability Policy (AU-6). It applies to the audit records of every system in the system inventory, whether they are on the central log platform or kept on the system.

Audit records are reviewed and analyzed [Fill in: frequency at which system audit records are reviewed and analyzed. Typical: continuously through automated alerting, with a documented manual review at least weekly], for indications of [Fill in: inappropriate or unusual activity. Typical: the activity listed in the log review procedure, such as repeated failed logons, privilege escalation and access outside normal patterns] and its potential impact (AU-6a). Review, analysis and reporting are integrated using [Fill in: automated mechanisms used for integrating audit record review, analysis, and reporting processes. Typical: a security information and event management (SIEM) platform] (AU-6(1)), and findings are reported to [Fill in: personnel or roles to receive findings from reviews and analyses of system records. Typical: the system owner and the incident response team] (AU-6b).

## 2. Roles

| Role | Responsibilities in this procedure |
| --- | --- |
| [Security operations team] | Runs the reviews, triages alerts, correlates records across systems, reports findings, and refers suspected incidents |
| [Fill in: security operations lead] | Assigns reviews, checks review records, signs off the monthly summary, and decides when the review level changes |
| [System owner] | Explains activity on the system, confirms whether it was authorized, fixes what the review finds, and makes sure system-level reviews happen |
| System administrators | Review the logs that stay on the system (5.3), and provide context on activity |
| [Incident response team] | Takes suspected incidents referred under 5.5 and handles them under the incident response plan |
| [Senior privacy official] | Receives findings that involve personally identifiable information |
| [Facilities manager] | Provides physical access records for correlation (High systems, 5.7) |
| [Chief Information Security Officer] | Owns this procedure, and receives the monthly summary |

## 3. Inappropriate or unusual activity

The review looks for the activity in this table. Each row has a saved search, report or detection rule on the central log platform, named in the last column.

| # | Activity | Where it shows | Compared with | Saved search or rule |
| --- | --- | --- | --- | --- |
| 1 | Repeated failed logons on one account, or failures spread across many accounts from one source | Authentication records | Normal failure rates | [Fill in: name] |
| 2 | A successful logon after repeated failures, or from an unusual location, device or time | Authentication records | The user's usual pattern | [Fill in: name] |
| 3 | Accounts created, enabled or given privileges | Account management and privilege records | Approved [access requests](https://kston83.github.io/nist-guide/templates/forms/access-request-form/) | [Fill in: name] |
| 4 | Use of privileged functions, emergency accounts, or dormant accounts; interactive use of service accounts | Privilege and authentication records | Approved change windows; emergency account use under the account management procedure | [Fill in: name] |
| 5 | Configuration changes and software installed outside approved change requests | Configuration and software records | Approved [change requests](https://kston83.github.io/nist-guide/templates/forms/change-request-form/) | [Fill in: name] |
| 6 | Logging stopped, changed or cleared; a log source gone silent; security tools disabled | Logging and security tool records; log source health report | The log sources expected from the component inventory | [Fill in: name] |
| 7 | Access to audit records, key stores or secrets by anyone outside the roles allowed | Security-relevant object records | The roles in the audit logging standard, section 9 | [Fill in: name] |
| 8 | Bulk access, export or deletion of sensitive information | Sensitive information and application records | The user's role and usual volume | [Fill in: name] |
| 9 | Connections to known malicious addresses or domains, unusual outbound volumes, or new external destinations | Network records | Threat intelligence indicators; normal traffic | [Fill in: name] |
| 10 | Repeated authorization failures or input validation failures in an application | Application records | Normal error rates | [Fill in: name] |
| 11 | Changes to cloud resources, identity settings or audit settings in the management console or programming interfaces | Cloud management records | Approved change requests | [Fill in: name] |
| 12 | Log entries of a type not seen before, or not yet understood | All sources | The record of entry types already reviewed | [Fill in: name] |
| 13 | [Fill in: other activity the organization or system owner adds] | [Fill in: source] | [Fill in: baseline] | [Fill in: name] |

> **Guidance:** NIST's AU-6 discussion says review covers logging from monitoring account usage, remote access, wireless connectivity, mobile device connection, configuration settings, system component inventory, maintenance tools and non-local maintenance, physical access, temperature and humidity, equipment delivery and removal, communications at system interfaces, and use of mobile code or Voice over Internet Protocol; add rows for any your systems log. SP 800-92 section 5.2.1 says the key to analysis is understanding typical activity, which comes from reviewing portions of the logs regularly, and suggests two reports: one for the entries thought most important, and one for entries not yet understood (row 12), so the baseline of normal activity grows. Section 5.2.2 suggests setting your own priorities from the entry type, whether it is new, the log source, the addresses involved, the time of day and the frequency.

## 4. Reduction and reporting capability

The central log platform provides the audit record reduction and report generation capability, so that reviews and investigations can run on demand (AU-7a). It is set up as follows:

- Records can be processed, sorted and searched for events of interest based on [Fill in: fields within audit records that can be processed, sorted, or searched. Typical: event type, time, source and destination, user identity, outcome and system component] (AU-7(1)).
- Saved searches, reports and dashboards for each row in section 3 run on demand and on the schedule in section 5.
- Reduction, filtering and reports work on copies or views of the records. The original records keep their content and time order, and filtered-out entries stay available (AU-7b).

| Capability | Tool | Owner | Last checked |
| --- | --- | --- | --- |
| Search by the fields in AU-7(1) | [Fill in: for example the SIEM platform] | [Fill in: role] | [Fill in: date] |
| Saved searches and reports for section 3 | [Fill in: tool] | [Fill in: role] | [Fill in: date] |
| Restoring archived records for search | [Fill in: tool] | [Fill in: role] | [Fill in: date] |

## 5. Procedures

Each step names the role that performs it, what it starts from, what it produces, and the record it leaves. The records are the evidence an assessor samples.

### 5.1 Triage automated alerts

| # | Role | Action | Inputs | Outputs | Record |
| --- | --- | --- | --- | --- | --- |
| 1 | [Security operations team] | Watch the alert queue on [Fill in: automated mechanisms used for integrating audit record review, analysis, and reporting processes. Typical: a security information and event management (SIEM) platform], which runs the detection rules for section 3 continuously (AU-6(1)) | Alerts | Alerts picked up within the triage times of section 6 of the system monitoring standard | Alert record, with the time it was picked up |
| 2 | [Security operations team] | Add context: the asset and its owner, the user and their role, related alerts, approved access requests and change requests, and recent vulnerability findings | Alert; inventories; tickets | Alert with context | Notes on the alert |
| 3 | [Security operations team] | Decide the outcome: false positive, benign and authorized, or a suspected incident; ask the [System owner] to confirm whether the activity was authorized when it cannot be told from the records | Alert with context; system owner's answer | Outcome | Outcome and a short note of what was checked, on the alert |
| 4 | [Security operations team] | Refer suspected incidents through 5.5; send other findings to the [System owner] through 5.4; record tuning needed for false positives | Outcome | Referral, finding or tuning request | Ticket or incident reference on the alert |

### 5.2 Weekly manual review

| # | Role | Action | Inputs | Outputs | Record |
| --- | --- | --- | --- | --- | --- |
| 1 | [Fill in: security operations lead] | Assign the review for the week, and name the systems in scope | Schedule | Assigned reviewer | Review record opened, with the period covered |
| 2 | [Security operations team] | Check log source health: every source expected from the component inventory is reporting, and gaps since the last review are explained (AU-5) | Log source health report; component inventory | Silent or failed sources listed | Health report attached to the review record |
| 3 | [Security operations team] | Run the saved searches for each row in section 3 over the period, and look at what the automated rules do not alert on (AU-6a) | Saved searches | Entries needing a closer look | List of searches run and result counts |
| 4 | [Security operations team] | Compare account, privilege and configuration changes with approved access requests and change requests; any change with no approval is a finding | Rows 3, 4, 5 and 11 results; tickets | Unapproved changes listed | Comparison, on the review record |
| 5 | [Security operations team] | Review entries not yet understood (row 12), find out what they mean, and add them to the baseline or to a detection rule | Row 12 results | Baseline or rules updated | Note of the entry types reviewed |
| 6 | [Security operations team] | Analyze the potential impact of each indication found, and decide the outcome as in 5.1 step 3 (AU-6a) | Entries needing a closer look | Findings, referrals, or nothing found | Each finding with its outcome |
| 7 | [Security operations team] | Close the review: report findings through 5.4 and 5.5, and sign the record | Findings | Signed review record | Review record, with the reviewer, date, period, systems, searches run, findings and to whom each was reported |
| 8 | [Fill in: security operations lead] | Check a sample of review records each month for completeness | Review records | Gaps fixed | Initials and date on the records checked |

### 5.3 System-level review of logs that stay on the system

Some records cannot reach the central log platform, such as those of standalone systems, appliances with unusual formats, or entries that only make sense with context on the system. The audit logging standard's Part B lists them.

| # | Role | Action | Inputs | Outputs | Record |
| --- | --- | --- | --- | --- | --- |
| 1 | System administrators | Review the local logs listed in Part B at least as often as the weekly review, for the activity in section 3 | Local logs | Findings, or nothing found | System-level review record, with the date, logs reviewed and result |
| 2 | System administrators | Send the review record and any findings to the [Security operations team], so they can look for the same activity on other systems | Review record | Record received | Review record filed with the weekly review |

### 5.4 Report findings

| # | Role | Action | Inputs | Outputs | Record |
| --- | --- | --- | --- | --- | --- |
| 1 | [Security operations team] | Report each finding that is not a suspected incident to [Fill in: personnel or roles to receive findings from reviews and analyses of system records. Typical: the system owner and the incident response team], with what was found, its potential impact, and what is asked of them (AU-6b) | Finding | Ticket assigned to the system owner | Ticket, dated |
| 2 | [Security operations team] | Report findings that involve personally identifiable information to the [Senior privacy official] as well | Finding | Notice | Ticket, with the privacy official added |
| 3 | [System owner] | Fix the cause, such as removing an unapproved account or reversing an unapproved change, and confirm it in the ticket | Ticket | Cause fixed | Ticket closed, with the action taken |
| 4 | [System owner] | Enter in the [plan of action and milestones](https://kston83.github.io/nist-guide/templates/forms/plan-of-action-and-milestones/) any finding that shows a control weakness and cannot be fixed at once | Finding | Plan of action and milestones item | Item ID on the ticket |

### 5.5 Refer suspected incidents

| # | Role | Action | Inputs | Outputs | Record |
| --- | --- | --- | --- | --- | --- |
| 1 | [Security operations team] | Refer the suspected incident to the [Incident response team] under the [incident response plan](https://kston83.github.io/nist-guide/templates/plans/incident-response-plan/), with the alert or finding, the records that support it and the systems involved | Suspected incident | Referral | Incident record opened, linked to the alert or review record |
| 2 | [Security operations team] | Preserve the related audit records: export copies with their hashes, and ask [Fill in: legal counsel] for a legal hold where the records may be needed beyond the retention period | Incident record | Preserved records | Export with hashes; legal hold request |
| 3 | [Security operations team] | Increase logging and review for the users, components or activity involved for as long as the investigation needs it, through the change process the audit logging standard sets | Request from the [Incident response team] | Logging and review increased | Change record; note on the incident record |
| 4 | [Security operations team] | Run searches across all systems for the same indicators (5.6), and add what is learned to detection rules and section 3 | Indicators from the incident | Other affected systems found, or none | Search results on the incident record |

### 5.6 Correlate across repositories

| # | Role | Action | Inputs | Outputs | Record |
| --- | --- | --- | --- | --- | --- |
| 1 | [Security operations team] | Analyze and correlate audit records across systems and repositories, such as the same source, account or indicator appearing on several systems, to gain organization-wide awareness (AU-6(3)) | Records from every system on the platform; repositories outside it | Correlated findings | Correlation rules list; findings on the review record |
| 2 | [Security operations team] | Where records sit in more than one repository, such as a cloud provider's logs or a separate platform, confirm they can be searched together or are brought together for the review | List of repositories | Gaps listed | Note on the monthly summary |

### 5.7 High systems: integrated analysis and physical access

This section applies to High systems.

| # | Role | Action | Inputs | Outputs | Record |
| --- | --- | --- | --- | --- | --- |
| 1 | [Security operations team] | Integrate analysis of audit records with analysis of [Select one or more: vulnerability scanning information; performance data; system monitoring information; [Assignment: organization-defined data/information collected from other sources]. Typical: vulnerability scanning information and system monitoring information], for example by checking whether an attack recorded in the logs targets a known vulnerability on that component (AU-6(5)) | Audit records; scan results; monitoring alerts | Findings with their vulnerability context | Correlation rule or review note |
| 2 | [Security operations team] | Correlate audit records with physical access monitoring records, such as a logon at a console when the badge records show the person was not in the facility (AU-6(6)) | Audit records; physical access records, such as the [physical access list](https://kston83.github.io/nist-guide/templates/forms/physical-access-list/) and access logs, from the [Facilities manager] | Findings, or nothing found | Correlation rule or review note |

### 5.8 Change the level of review

| # | Role | Action | Inputs | Outputs | Record |
| --- | --- | --- | --- | --- | --- |
| 1 | [Fill in: security operations lead] | Increase the frequency, scope or depth of review when law enforcement information, intelligence information or other credible sources show a change in risk, such as a threat advisory naming the organization's technology (AU-6c) | Advisory or report | Review increased: more frequent manual reviews, new searches, or more systems in scope | Decision, with the reason, the change made and the end date |
| 2 | [Fill in: security operations lead] | Return the review to its normal level when the risk passes, and record why | Updated information | Normal review | Decision record closed |

### 5.9 Monthly summary

| # | Role | Action | Inputs | Outputs | Record |
| --- | --- | --- | --- | --- | --- |
| 1 | [Security operations team] | Summarize the month: reviews done against the schedule, alerts by outcome, findings by system and status, suspected incidents referred, silent log sources, and changes to searches and rules | Review records; alert records; tickets | Monthly summary | Monthly summary |
| 2 | [Fill in: security operations lead] | Sign off the summary and send it to the [Chief Information Security Officer] and the system owners | Summary | Summary sent | Summary, with the sign-off and distribution |

> **Guidance:** SP 800-92 section 5.2.3 says system-level administrators usually review the entries that never reach the central infrastructure, and are often asked to report their results so the infrastructure team can see patterns across systems, such as the same attack tried on several hosts, which is 5.3 and 5.6. Section 5.3 says administrators who find a likely incident follow the incident response procedures, should be ready to give incident handlers copies of logs, and may need to change logging during a response, such as collecting more data on an activity; that is 5.5. The monthly summary also serves the system monitoring standard's reporting (SI-4g) and the Continuous Monitoring Strategy's event and incident management row.

#### 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) (May 22, 2026), Appendix B item 5, requires agencies to collect logs that support monitoring for suspicious activity identified by security tooling, monitoring, detecting and hunting for known indicators of compromise and for anomalous system or user activity, and generating automated alerts for these; rows 6, 9 and 12 of section 3, and 5.1, are where this procedure does that. The memo also requires that, in the event of a known or suspected compromise of one or more federal networks, agencies provide logs and other relevant data to CISA and the FBI upon request, to the extent consistent with applicable law, in a format and by means agreed with them, and within the timeframes they request to the greatest extent practicable. When such a request arrives, the [Incident response team] handles it under the incident response plan, and the [Security operations team] exports the records as in 5.5 step 2. The memo does not apply to national security systems. As of October 2026.

## 6. Records

| Record | Kept in | Retention |
| --- | --- | --- |
| Alert records, with outcomes | [Fill in: for example the SIEM platform or case management tool] | [Fill in: for example 3 years] |
| Weekly and system-level review records | [Fill in: location] | [Fill in: for example 3 years, or at least until the next assessment] |
| Findings tickets | [Fill in: for example the service management tool] | [Fill in: period] |
| Decisions to change the level of review | [Fill in: location] | [Fill in: period] |
| Monthly summaries | [Fill in: location] | [Fill in: period] |
| The audit records themselves | The central log platform | As the audit logging standard sets (AU-11) |

## 7. Review

The [Chief Information Security Officer] reviews this procedure [Fill in: for example annually], and after assessment or audit findings, security incidents that the review missed or found late, and changes to the central log platform or the event list.

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