Audit and Accountability Procedure

Approval #

Revision History #

Review cycle: Every year, under the Policy and Procedure Management Policy.

1. Purpose #

The people named in this procedure use it to carry out the AU control family policy (POL-AU). It covers every control in the audit and accountability family. The steps, the people responsible, and the evidence below show how the Organization meets those National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 controls. They also support the Inspector General (IG) Federal Information Security Modernization Act (FISMA) reporting metrics.

This general procedure covers every control in the AU family. A system that departs from it, or adds to it, has its own system-specific procedure for those controls.

2. Scope #

This procedure applies to every information system that the Organization operates, or that others operate for it, under the low security baseline.

2.1 CSF 2.0 Alignment #

The steps in this procedure support these NIST Cybersecurity Framework (CSF) 2.0 categories:

• DE.CM — Continuous Monitoring (Detect function)
• DE.AE — Adverse Event Analysis (Detect function)
• RS.AN — Incident Analysis (Respond function)

3. Controls Covered #

This procedure covers the following 13 controls in the AU family:

3.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the AU control family. They add to the NIST SP 800-53 control requirements that the Procedure section carries out.

OMB M-22-01: Improving Detection of Cybersecurity Vulnerabilities and Incidents through EDR

• The organization must deploy Endpoint Detection and Response (EDR) across the enterprise, with visibility across all components, to improve detection of cybersecurity vulnerabilities and threats. (OMB M-22-01, §2)

NIST SP 800-61 Rev 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management

• The organization must ensure incident detection uses logging and monitoring data, with defined alerting thresholds and escalation procedures. Audit log data must be sufficient to support incident analysis and reconstruction. (NIST SP 800-61r3, §3.2)

CISA High Value Asset (HVA) Control Overlay v1.0

• The organization must implement enhanced audit review, analysis, and reporting for HVAs per the overlay’s AU-6 enhancement selections (including AU-6(3) correlation across repositories and AU-6(4) central review and analysis). (CISA HVA Control Overlay v1.0, AU-6(3)/(4))

OMB M-26-14: Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats

• The organization must organize and resource logging around two objectives: continuous event monitoring (real-time detection and response of anomalous network activity, typically through the security operations center) and threat hunting, investigation, response, and forensics after a known or suspected compromise. Apply both objectives to every information system the organization owns or operates, including systems run by third parties on its behalf and any Internet of Things or operational technology that is part of a system. (OMB M-26-14, Prioritization)
• The organization must retain logs so they are actively searchable for at least 6 months after creation and retrievable for at least 12 months after creation. Retention for cybersecurity does not shorten any records-schedule obligation. Log storage may be decentralized, but logs must be readily available to the top-level security operations center. Deadline: Searchable ≥ 6 months; retrievable ≥ 12 months. (OMB M-26-14, Appendix B ¶1-2)
• The organization must collect, at a minimum, logs that identify the identity used for operations, source and destination network addresses (protocols, ports, session attributes), object and data events (accessed, modified, destroyed), privilege changes, changes to IT/OT/IoT infrastructure, alerts from security tooling, known indicators of compromise, anomalous system or user activity, data affected in an incident, and attack vectors including initial access and lateral movement — and generate automated alerts for all of them. (OMB M-26-14, Appendix B ¶5)
• The organization must stamp every log with a consistently accurate timestamp, with network time synchronized through NTP or an equivalent mechanism to a traceable time source designated within the organization (preferably one traceable to the U.S. Naval Observatory or NIST). Use CDM, hardware asset management, and software asset management data to confirm log coverage reaches all information technology, including IoT and OT. (OMB M-26-14, Appendix B ¶3-4)
• The organization must submit an Agency Logging Plan to OMB and CISA within 90 days of publication of the CISA Logging Reference Architecture, describing the operational steps to deploy and maintain continuous event monitoring and threat hunting, investigation, response, and forensics capabilities; update the plan within 30 days of any CISA notice of an updated reference architecture. Measure and report progress as the percentage of systems at each level of the logging maturity model (inventory visibility, collection coverage, collection operations, data retention, log management). Deadline: Plan due 2026-11-18; Level 1 by 2026-12-18; Level 2 at +180 days; Level 3 at +320 days after the LRA. (OMB M-26-14, Agency Logging Plan; Agency Actions; Appendix C)

CISA Logging Reference Architecture (companion to OMB M-26-14)

• The organization must build continuous event monitoring and threat hunting, investigation, response, and forensics capabilities to the CISA Logging Reference Architecture — prioritizing High Value Assets and high-impact systems, aligning with the Zero Trust Maturity Model visibility and analytics capability, centralizing logs or centralized access at the highest-level security operations center, and protecting the confidentiality and integrity of sensitive log data. Deadline: Adhere on the M-26-14 timelines. (CISA LRA (per OMB M-26-14 Appendix A))

36 CFR Part 1236: Electronic Records Management

• The organization should build records controls into each system that holds federal records, or into a separate recordkeeping system, including audit trails that keep records complete and unaltered. (36 CFR 1236.10)

NARA GRS 6.1: Email and Other Electronic Messages Managed under a Capstone Approach

• The organization should apply GRS 6.1 to email only after NARA approves the Organization’s form NA-1005, and then apply it to all email records. (NARA GRS 6.1)

4. Procedure #

4.1 General Implementation Approach #

The Organization implements the AU controls in two ways: as organization-wide common controls that systems inherit, and as system-specific implementations where a system needs them. The control-specific procedures below cover each control in the Audit and Accountability family.

The Common Control Provider (CCP) implements controls marked inherited for the whole Organization. The CCP and each System Owner share the work for controls marked hybrid. Each System Owner implements controls marked customer-configured for the system.

Responsible party: The Information System Security Officer (ISSO) / Audit Log Reviewer carries out the steps in this procedure unless a control-specific procedure names someone else. The System Owner is accountable for funding and completing the work. The CISO oversees the procedure and receives its performance measures. See the AU policy (POL-AU) for the role definitions.

4.2 Control-Specific Procedures #

AU-01 — Policy and Procedures #

Baselines: Low / Moderate / High / Privacy CSF 2.0: DE.CM (Continuous Monitoring)

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business process-level; system-level — to be defined] audit and accountability policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the audit and accountability policy and the associated audit and accountability controls;

2. Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the audit and accountability policy and procedures; and
3. Review and update the current audit and accountability:

1. Policy at least every 3 years and following significant changes; and
2. Procedures at least annually and following [Assignment: organization-defined events — to be defined].

Procedure:

The CISO owns the audit and accountability policy and this procedure as controlled documents with a version history. The CISO’s office schedules the review every 3 years and opens the review in the policy library in the document management system. The assigned author gathers input from System Owners, Application Owners, and ISSOs, and records the decision on every comment. The record closes only when the CISO approves the revision. A major incident or a major change to applicable policy opens a review record sooner, on the same routing.

For each revision, the author checks the documents against the current federal logging directives. These are the M-26-14 minimum logging baseline, maturity model, and retention floors; the Cybersecurity and Infrastructure Security Agency (CISA) Logging Reference Architecture; and the M-22-01 endpoint visibility expectations. This check keeps the documents aligned with the requirements that assessors measure the Organization against. The CISO’s office publishes the approved version, records the distribution to the Authorizing Official, System Owners, Application Owners, and ISSOs in the review record, and archives the superseded version.

Evidence: the review records with their comment decisions and approvals, the version history, the directive crosswalk notes, and the distribution records.

AU-02 — Event Logging #

Baselines: Low / Moderate / High / Privacy / HVA overlay CSF 2.0: DE.CM (Continuous Monitoring), DE.AE (Adverse Event Analysis)

1. Identify the types of events that the system is capable of logging in support of the audit function: successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes;
2. Coordinate the event logging function with other organizational entities requiring audit-related information to guide and inform the selection criteria for events to be logged;
3. Specify the following event types for logging within the system: Assignment: organization-defined 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];
4. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and
5. Review and update the event types selected for logging annually and whenever there is a change in the threat environment.

Procedure:

For each system, the System Owner keeps a catalog of the event types the system can log, the subset the system does log, and a written rationale that the subset supports reconstruction of an incident. The ISSO validates the selection against the M-26-14 minimum baseline and the CISA Logging Reference Architecture. The ISSO coordinates it with the Security Operations Center (SOC) before it takes effect.

Each log source connects to the security information and event management (SIEM) system through a data connector, and ingestion runs in near real time. The SOC confirms that each new source is reporting before the onboarding ticket closes. The EDR tools supply the endpoint telemetry that Office of Management and Budget (OMB) M-22-01 expects. The cloud platform workloads forward their platform and service logs through the same pipeline.

The System Owner reviews the selection every year. The System Owner also reviews it at once when OMB or CISA changes the logging baseline or maturity model, or when the system’s threat environment changes. Every change goes through a ticketing system change record with the ISSO’s concurrence.

Evidence: the event catalogs and rationales, the SIEM system source inventory, the onboarding and change tickets, and the annual review records.

AU-03 — Content of Audit Records #

Baselines: Low / Moderate / High CSF 2.0: DE.CM (Continuous Monitoring), DE.AE (Adverse Event Analysis)

Ensure that audit records contain information that establishes the following: a. What type of event occurred; b. When the event occurred; c. Where the event occurred; d. Source of the event; e. Outcome of the event; and f. Identity of any individuals, subjects, or objects/entities associated with the event.

Procedure:

The ISSO proves record content at onboarding. When a source connects to the SIEM system, the ISSO and the SOC pull sample records and verify that the event type, timestamp, location, source, outcome, and identity fields are present and populated. A missing field opens a ticketing system ticket against the owning System/Application Administrator. The ISSO does not accept the source as compliant until the fields resolve.

The ISSO checks completeness again when a system change alters what a component logs or how it logs it. Analysts who find a content gap during routine review flag it at once, so the record of the deficiency starts when someone finds it and not at the next reassessment. The ISSO screens record content for information about individuals that goes beyond the audit purpose and removes the excess from the configuration.

Evidence: the onboarding verification captures, the deficiency tickets and their closures, the re-verification notes tied to change records, and the privacy screening results.

AU-03(3) — Limit Personally Identifiable Information Elements #

Baselines: Privacy

Limit personally identifiable information contained in audit records to the following elements identified in the privacy risk assessment: [Assignment: organization-defined elements — to be defined].

Procedure:

During the privacy risk assessment, the Privacy Officer lists the personally identifiable information (PII) elements that each system may write to its audit records. The ISSO compares that list with the event fields the system sends to the SIEM system and to the EDR tool.

If an event carries a PII field outside [AU-03(3) parameter 1 — to be defined], the ISSO asks the System Owner in writing to mask or remove it. The System Owner’s staff change the logging configuration. The ISSO then searches recent events in the SIEM system to confirm the field no longer appears. A request to add a PII element goes to the Senior Agency Official for Privacy (SAOP), who records a decision before anyone changes the configuration.

Evidence: the privacy risk assessment element list, the ISSO comparison record, the configuration change record, the confirming search results, and any SAOP decision.

AU-04 — Audit Log Storage Capacity #

Baselines: Low / Moderate / High CSF 2.0: DE.CM (Continuous Monitoring)

Allocate audit log storage capacity to accommodate [Assignment: organization-defined audit log retention requirements — to be defined].

Procedure:

The SIEM system holds the central log capacity. The SOC configures the workspace for [AU-04 parameter 1 — to be defined] of active retention, with a transition to cold storage that runs through month 30. The SOC monitors ingestion volume and storage consumption across the workspace. When a source’s volume grows beyond its projection, the SOC starts a capacity review. When consumption approaches a threshold, the SOC opens a ticketing system capacity action before any data is at risk.

The System Owner declares the expected log volume for a new system as part of onboarding. For workloads hosted in the cloud platform, administrators size the log forwarding and any local buffering so a short outage does not drop events. Where a component buffers locally, the administrator confirms that the buffer covers a realistic interruption window.

The SOC records each capacity decision and its rationale, so the growth of the store is as auditable as the data in it. Evidence: the retention configuration export, the consumption reports, the onboarding volume declarations, and the capacity action tickets with their resolutions.

AU-05 — Response to Audit Logging Process Failures #

Baselines: Low / Moderate / High CSF 2.0: DE.CM (Continuous Monitoring)

1. Alert [Assignment: organization-defined personnel or roles — to be defined] within [Assignment: organization-defined time period — to be defined] in the event of an audit logging process failure; and
2. Take the following additional actions: overwrite oldest record.

Procedure:

Health monitoring in the SIEM system flags a source that stops reporting, an agent that fails, and storage that approaches exhaustion. The alert reaches the System/Application Owner, the ISSO, and the System/Application Administrators in near real time. Each alert opens a ticketing system record. The administrator restores the failed component, and the ISSO verifies that events are flowing again before the record closes.

The ISSO assesses the gap after every outage: the affected sources, the duration, and the activity that went unrecorded. The SOC decides whether the gap requires investigation as an incident. When storage caused the failure, the SOC hands the problem to the capacity procedure, so the fix addresses the cause and not only the symptom.

Evidence: the health alert rules, the alert and restoration records with their timestamps, the gap assessments, and the tickets that link each outage to its root-cause action.

AU-06 — Audit Record Review, Analysis, and Reporting #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: DE.CM (Continuous Monitoring), DE.AE (Adverse Event Analysis), RS.AN (Incident Analysis)

1. Review and analyze system audit records at least weekly for indications of [Assignment: organization-defined inappropriate or unusual activity — to be defined] and the potential impact of the inappropriate or unusual activity;
2. Report findings to [Assignment: organization-defined personnel or roles — to be defined]; and
3. Adjust the level of audit record review, analysis, and reporting within the system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information.

Procedure:

The SOC works in the SIEM system, where analytics rules and scheduled queries bring up the minimum indicator set. That set covers starts and stops, network changes, security setting changes, logon and post-logon activity, account and privilege changes, and application-level anomalies. Analysts review moderate-impact and high-impact systems every week and low-impact systems every week. Detections from the EDR tools arrive in the same queue, so analysts read endpoint signals and log signals together.

Analysts decide each item. They annotate a benign item. They turn a suspicious item into a SIEM system incident and open a ticketing system record to the System/Application Owner, the ISSO, and the administrators. When the CISO directs a risk-based adjustment on credible threat information, the SOC widens the scope or the frequency of review and documents the change and its trigger.

Evidence: the analytics rule inventory, the review and triage logs, the escalation records with their recipients, and the adjustment directives with their rationale.

AU-08 — Time Stamps #

Baselines: Low / Moderate / High CSF 2.0: DE.CM (Continuous Monitoring)

1. Use internal system clocks to generate time stamps for audit records; and
2. Record time stamps for audit records that meet one second granularity of time measurement and that use Coordinated Universal Time, have a fixed local time offset from Coordinated Universal Time, or that include the local time offset as part of the time stamp.

Procedure:

System/Application Administrators configure every component to synchronize its clock with the authoritative time source for its environment. The cloud platform workloads use the platform’s time service, and on-premises components chain to the same reference. The administrators hold timestamps within the 10-millisecond tolerance and stamp records in Coordinated Universal Time (UTC) or with a fixed, documented offset from it.

The ISSO verifies timing at onboarding by comparing timestamps across sources for the same activity in the SIEM system. The ISSO checks again when analysts report a sequencing anomaly during review. When a component drifts beyond tolerance, the ISSO opens a ticketing system ticket to the owning administrator. After the fix, the ISSO compares the timestamps again to confirm it.

Evidence: the time synchronization configuration exports, the onboarding verification results, the drift tickets with their closure checks, and the analyst reports that triggered an out-of-cycle check.

AU-09 — Protection of Audit Information #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: DE.CM (Continuous Monitoring)

1. Protect audit information and audit logging tools from unauthorized access, modification, and deletion; and
2. Alert [Assignment: organization-defined personnel or roles — to be defined] upon detection of unauthorized access, modification, or deletion of audit information.

Procedure:

The SOC limits access to the SIEM system workspace, its data, and the log transport pipeline to authorized roles, and keeps the list of grants short. The workspace’s own activity log captures every change to retention settings, analytics rules, data connectors, and stored data, so the audit system records changes to itself.

Detection rules watch for the signs of tampering: log deletion, permission changes on audit stores, disabled connectors, and modified rules. A detection alerts the System/Application Owner, the ISSO, and the System/Application Administrators, and opens a ticketing system security record. The SOC investigates the record as a potential incident. The ISSO re-validates the rights to manage audit information during the Organization’s privileged access reviews.

Evidence: the role and permission exports, the tamper detection rules, the alert and investigation records, and the activity log of changes to the logging configuration.

AU-10 — Non-repudiation #

Baselines: High / HVA overlay (applies to systems designated as High Value Assets, under OMB M-19-03) CSF 2.0: DE.CM (Continuous Monitoring)

Provide irrefutable evidence that an individual (or process acting on behalf of an individual) has performed [Assignment: organization-defined actions — to be defined].

Procedure:

System Owners and administrators configure each system and application to write audit records that name the actor for every required action. Each record shows the account, the source address, the action, the object affected, and the result. The EDR tool collects endpoint telemetry that links process activity to the signed-in user. Systems forward their records to the SIEM system, which stores them where administrators of the source system cannot alter them.

When an investigation must prove who performed an action, security operations center analysts search the SIEM system. They trace the action from the record back to the authenticated account and the person who owns it. The ISSO checks each system’s log sources against the required action list during authorization and after major changes. The ISSO records any gap as a weakness for the System Owner to fix.

Evidence: system logging settings, the SIEM system data source list, investigation records that show attribution, and ISSO coverage checks.

AU-11 — Audit Record Retention #

Baselines: Low / Moderate / High / Privacy CSF 2.0: DE.CM (Continuous Monitoring)

Retain audit records for a time period in compliance with OMB M-26-14 to provide support for after-the-fact investigations of incidents and to meet regulatory and organizational information retention requirements.

Procedure:

The SIEM system applies the retention schedule automatically. Records stay a time period in compliance with OMB M-26-14 in active storage, move to cold storage, and complete 30 months of retention before disposal. The platform logs each transition and each disposal, so the life cycle of the data is itself auditable.

The SOC flags records tied to a legal hold or an open investigation and excludes them from disposal until the hold is formally released. The hold register records who imposed the hold, why, and when it lifted. A requester asks for a retrieval from cold storage through the ticketing system. The SOC carries out the retrieval and records the turnaround time, so the Organization knows that it can reach older records when it needs them.

Evidence: the retention configuration export, the transition and disposal logs, the hold register with its release decisions, and the retrieval request records with their timing.

AU-12 — Audit Record Generation #

Baselines: Low / Moderate / High CSF 2.0: DE.CM (Continuous Monitoring), DE.AE (Adverse Event Analysis)

1. Provide audit record generation capability for the event types the system is capable of auditing as defined in AU-2a on all information system and network components where audit capability is deployed/available;
2. Allow [Assignment: organization-defined personnel or roles — to be defined] to select the event types that are to be logged by specific components of the system; and
3. Generate audit records for the event types defined in AU-2c that include the audit record content defined in AU-3.

Procedure:

Administrators confirm audit record generation at deployment. They enable audit logging on each component as it enters service. The EDR tools cover endpoints, the cloud platform provides platform and service logging, and servers use native operating system and application logging. The System/Application Owner records the event-type selection for each component class and applies the OMB category floors that apply.

The ISSO checks the SIEM system to confirm that each component reports and that its records carry the required content. A silent or malformed source opens a ticketing system ticket against the owning administrator. The ticket closes only when the ISSO sees records arriving, and not on a reported fix alone. The System/Application Owner approves every change to an event-type selection, and no change may go below the OMB floor.

Evidence: the component logging configurations, the selection records, the SIEM system source inventory, and the silent-source tickets with their verified closures.

AU-16 — Cross-organizational Audit Logging #

Baselines: HVA overlay (applies to systems designated as High Value Assets, under OMB M-19-03)

Employ [Assignment: organization-defined methods — to be defined] for coordinating [Assignment: organization-defined audit information — to be defined] among external organizations when audit information is transmitted across organizational boundaries.

Procedure:

Before a new exchange with an outside organization goes live, the ISSO lists the audit information each side needs to trace activity across the boundary. The ISSO agrees with the other organization’s security contact on [AU-16 parameter 1 — to be defined] for sharing [AU-16 parameter 2 — to be defined]. The System Owner adds those terms to the information exchange agreement and signs it with the other organization.

The system administrators configure the system to record the identity of the person or process that starts each request. They also record the identifier the other organization returns, so analysts can match the two records. The Security Operations Center confirms that the shared records reach central log storage and keep accurate timestamps.

When an incident crosses the boundary, the Security Operations Center asks the other organization for its records under the agreement. The ISSO reviews the terms each year and when the exchange changes.

Evidence: the signed information exchange agreements with their audit terms, the system configuration records, sample matched records from both sides, and the yearly review notes.

5. Parameters (ODP Values) #

The following organization-defined parameters apply to controls in this family:

6. Evidence Artifacts #

Carrying out this procedure produces these records:

• Audit logging configuration documentation
• Audit log retention policy
• Audit log review records (weekly/monthly)
• Audit log sample (evidence of content)
• Evidence for IG FISMA metric IR.01
• Evidence for IG FISMA metric IR.02
• Evidence for IG FISMA metric IR.32

7. Performance Measurement #

The CISO measures this procedure with the indicators below, which meet IG FISMA Level 4 (Managed and Measurable). The ISSO collects the data, and the CISO trends and reports it. When a measure moves away from its target, the CISO starts corrective action through the plan of action and milestones (POA&M) process.

8. Training Requirements #

Before they carry out the steps in this procedure, and every year after, the people who perform them must complete:

• General security awareness training, which all personnel take under POL-AT.
• Role-based training on this procedure’s steps, tools, and evidence.
• Training on the technology platforms listed under Technology Implementation, matched to their duties.

Completion is a condition of continued access. The Agency Learning Management System (LMS) holds the completion records.

9. Governance References #

• 36 CFR Part 1236: Electronic Records Management, current text.
• CISA Logging Reference Architecture (companion to OMB M-26-14), August 20, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• OMB M-22-01: Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Systems through Endpoint Detection and Response (EDR), October 8, 2021.
• OMB M-26-14: Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats, May 22, 2026.
• NARA General Records Schedule 6.1: Email and Other Electronic Messages Managed under a Capstone Approach, January 2023.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• CISA High Value Asset (HVA) Control Overlay v1.0, November 1, 2017.
• CISA Zero Trust Maturity Model, April 11, 2023.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.