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 high 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 29 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 annually 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 year 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(1) — Additional Audit Information #

Baselines: Moderate / High

Generate audit records containing the following additional information: session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon; individual identities of group account users; full-text of privileged commands.

Procedure:

System/Application Administrators apply the field standard when a source onboards. They configure each source to produce the fields the CISA Logging Reference Architecture calls for, as far as the source supports them. The fields are timestamps, status codes, device and session identifiers, network addresses, and user and command detail where applicable. They format the data as key-value pairs when the platform allows. The ISSO runs sample queries in the SIEM system to verify that the fields are present, and records each gap as a ticketing system item against the owning administrator. When a source cannot produce a field, the ISSO records the limitation in the open-limitation register. Evidence: the source configuration records, the verification queries and their output, and the open-limitation register.

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-05(1) — Storage Capacity Warning #

Baselines: High

Provide a warning to [Assignment: organization-defined personnel, roles, and/or locations — to be defined] within [Assignment: organization-defined time period — to be defined] when allocated audit log storage volume reaches 75%, or one month before expected negative impact of repository maximum audit log storage capacity.

Procedure:

System/Application Administrators configure a capacity alert on each audit log repository, including the SIEM system workspace and the cloud platform log stores. Each alert watches used storage against the threshold. When storage crosses the threshold, the alert notifies [AU-05(1) parameter 1 — to be defined]. The administrators then add capacity, archive older records, or adjust collection. The ISSO confirms that the warning and the response happened on time.

Evidence: alert rule configurations, alert notifications with timestamps, and records of the capacity actions taken.

AU-05(2) — Real-time Alerts #

Baselines: High

Provide an alert within real-time to service provider personnel with authority to address failed audit events when the following audit failure events occur: audit failure events requiring real-time alerts, as defined by organization audit policy.

Procedure:

The security operations center maintains detection rules in the SIEM system that watch for audit failures. These include stopped log sources, failed agents, and disabled collection. The EDR tools report endpoint sensors that stop sending data. When a rule fires, the SIEM system sends an alert to the System/Application Owner, the ISSO, and the System/Application Administrators. The administrators restore logging and record the cause. The ISSO confirms that collection has resumed and closes the alert.

Evidence: the detection rule definitions, alert records with timestamps, and restoration notes for each failure.

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-06(1) — Automated Process Integration #

Baselines: Moderate / High

Integrate audit record review, analysis, and reporting processes using [Assignment: organization-defined automated mechanisms — to be defined].

Procedure:

Every in-scope source reports to the SIEM system. Analytics rules, watchlists, and scheduled reports in the SIEM system run the review workflow. An incident that correlation generates routes to the SOC queue and opens a ticketing system record automatically, so analysis and response share one record. The SOC maintains the export feed to the Agency-wide log aggregation capability as a configuration item and verifies it when sources or schemas change. During onboarding, each system’s ISSO confirms that the system’s records take part in the automated review and do not sit in an unwatched store. Evidence: the connector and export configurations, the analytics rule inventory, and the incidents and reports the pipeline generates.

AU-06(3) — Correlate Audit Record Repositories #

Baselines: Moderate / High

Analyze and correlate audit records across different repositories to gain organization-wide situational awareness.

Procedure:

The SOC builds and maintains the correlation rules in the SIEM system. The rules join endpoint detections from the EDR tools with identity, cloud, and application events from the cloud platform and the other onboarded sources. The resulting incidents carry the full cross-source picture. The SOC investigates each correlated incident as a single case and records which repositories contributed and what the combination showed that no single source did. The SOC tunes the rules as new sources onboard, so coverage grows with the environment. Evidence: the correlation rule definitions, the correlated incident records, and the case notes that show multi-repository analysis.

AU-06(4) — Central Review and Analysis #

Baselines: High

Provide and implement the capability to centrally review and analyze audit records from multiple components within the system.

Procedure:

System/Application Administrators connect each system component to the SIEM system through data connectors or forwarding agents. These sources include servers, endpoints through the EDR tools, the cloud platform services, and applications. Analysts in the security operations center search, correlate, and review the combined records in the workspace. They build analytics rules and run investigations across all sources at once. When a component stops sending records, the ISSO works with the administrators to restore the connection.

Evidence: the list of connected data sources, analytics rule definitions, investigation records, and ingestion health reports.

AU-06(5) — Integrated Analysis of Audit Records #

Baselines: High

Integrate analysis of audit records with analysis of vulnerability scanning information; performance data; information system monitoring information; penetration test data; {{ insert: param, au-06.05_odp.02 }} to further enhance the ability to identify inappropriate or unusual activity.

Procedure:

System/Application Administrators send scan results, performance data, and system and application monitoring data to the SIEM system along with audit records. The EDR tools add endpoint telemetry and vulnerability data. Analysts in the security operations center write analytics rules that join audit events with these other sources. For example, a rule can link a failed attack to a known weakness on the target host. Analysts review the combined results during each investigation and record which sources informed the conclusion.

Evidence: data source connections, analytics rule definitions, and investigation records that cite the combined sources.

AU-06(6) — Correlation with Physical Monitoring #

Baselines: High

Correlate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual, or malevolent activity.

Procedure:

Physical access records are loaded into the SIEM system next to logon and audit records. Analysts in the security operations center build rules that compare a person’s building entry with that person’s logon activity. For example, a rule flags an on-site logon when no badge entry exists for that day. Analysts investigate each flagged case and record the outcome. The ISSO reviews the combined records during insider threat and account misuse investigations.

Evidence: the physical access data feed, the comparison rule definitions, and investigation records for each flagged case.

AU-06(7) — Permitted Actions #

Baselines: High

Specify the permitted actions for each information system process; role; user associated with the review, analysis, and reporting of audit record information.

Procedure:

The ISSO records, for each role, process, and user that handles audit records, the actions it may take. Account managers create matching roles in the SIEM system and in the cloud platform access controls. Analysts receive read and query rights. Only a small set of administrators may change retention or delete data. Service processes receive the narrow rights they need to write logs. During account reviews, the ISSO compares actual assignments with the documented rights and removes any excess.

Evidence: the documented rights for each role, role assignment exports, and account review records.

AU-07 — Audit Record Reduction and Report Generation #

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

Provide and implement an audit record reduction and report generation capability that: a. Supports on-demand audit record review, analysis, and reporting requirements and after-the-fact investigations of incidents; and b. Does not alter the original content or time ordering of audit records.

Procedure:

Analysts work with the data in the SIEM system using queries and workbooks that filter, sort, aggregate, and summarize records from every onboarded source. Analysts generate reports for investigations, assessments, and audit requests from stored queries, so anyone can reproduce a result later. The analyst keeps the query text with the output and attaches both to the ticketing system record that requested the report.

Reduction never edits the source records. A summary is a view that the query computes, and the workspace keeps the originals with their content and order as captured. When a requester needs a recurring report, the SOC turns the query into a scheduled report so no one has to rebuild it by hand each time.

Evidence: the saved query and workbook library, the generated reports with their query provenance, the request tickets they attach to, and the intact source records the reports came from.

AU-07(1) — Automatic Processing #

Baselines: Moderate / High

Provide and implement the capability to process, sort, and search audit records for events of interest based on the following content: [Assignment: organization-defined fields within audit records — to be defined].

Procedure:

The query language in the SIEM system exposes the standard record fields. The SOC maintains a library of saved searches keyed to those fields: identity, event type, location, date and time, resource, address, and object. When an analyst works a case, the analyst pulls records by any combination of those criteria and exports the results, with the query that produced them, into the ticketing system case record. When a new log source is onboarded, the ISSO confirms that its fields are searchable, using the same key-value formatting the record content standard requires. Evidence: the saved search library, the case exports with their query provenance, and the onboarding searchability checks.

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-09(2) — Store on Separate Physical Systems or Components #

Baselines: High

Store audit records at least weekly in a repository that is part of a physically different system or system component than the system or component being audited.

Procedure:

System/Application Administrators install forwarding agents or data connectors that send each component’s audit records to the SIEM system as they are written. The EDR tools send endpoint telemetry to the same workspace. The workspace runs on the cloud platform infrastructure that is separate from the systems it receives logs from. Administrators of monitored systems do not receive delete rights in the workspace. The ISSO checks ingestion health reports for sources that have stopped or fallen behind and has administrators fix them.

Evidence: the forwarding configurations, the ingestion health reports, and the workspace access role assignments.

AU-09(3) — Cryptographic Protection #

Baselines: High

Implement cryptographic mechanisms to protect the integrity of audit information and audit tools.

Procedure:

System/Application Administrators enable cryptographic integrity features on each log store. For the cloud platform log storage, they turn on immutable, write-once retention and hash checks. Records travel to the SIEM system over encrypted, authenticated connections. Administrators install logging agents and tools only from signed packages, and the platforms check those signatures before installation. The ISSO reviews the integrity settings after each change to logging infrastructure. The ISSO opens an investigation when an integrity check fails.

Evidence: storage integrity configurations, signature verification records, integrity check results, and investigation records.

AU-09(4) — Access by Subset of Privileged Users #

Baselines: Moderate / High

Authorize access to management of audit logging functionality to only [Assignment: organization-defined subset of privileged users or roles — to be defined].

Procedure:

A small, named set of privileged accounts holds the audit-management rights in the SIEM system and the log pipeline, and the Organization uses those accounts for that purpose only. A person requests audit-management access through a ticketing system request, and the ISSO concurs before the grant. The grant record lists the other administrative duties the holder carries, so the approver checks the separation at approval. When a holder’s duties change, the ISSO re-evaluates the access before it continues. The ISSO re-validates the roster of audit-privileged accounts during the privileged access reviews. Evidence: the role assignment export, the approval tickets with their separation checks, and the re-validation records.

AU-10 — Non-repudiation #

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

Provide irrefutable evidence that an individual (or process acting on behalf of an individual) has performed minimum actions including the addition, modification, deletion, approval, sending, or receiving of data.

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-12(1) — System-wide and Time-correlated Audit Trail #

Baselines: High

Compile audit records from all network, data storage, and computing devices into a system-wide (logical or physical) audit trail that is time-correlated to within [Assignment: organization-defined level of tolerance — to be defined].

Procedure:

Administrators set each component’s clock to the designated time source and forward its audit records to the SIEM system. The EDR tool sends endpoint telemetry to the same repository. The SIEM system normalizes timestamps so analysts can place events from different components on one timeline. The ISSO compares component clocks with the reference time and assigns any drift beyond the allowed tolerance to the System Owner. The ISSO also confirms that every component in the inventory sends records. Evidence: time synchronization settings, the SIEM system source list, drift checks, and records of each correction.

AU-12(3) — Changes by Authorized Individuals #

Baselines: High

Provide and implement the capability for service provider-defined individuals or roles with audit configuration responsibilities to change the logging to be performed on all network, data storage, and computing devices based on [Assignment: organization-defined selectable event criteria — to be defined] within [Assignment: organization-defined time thresholds — to be defined].

Procedure:

When storage runs low, processing fails, or a defined event criterion applies, the System Owner decides whether to raise, lower, or redirect logging. An authorized administrator applies the change through the system’s logging settings or the SIEM system collection rules. The administrator confirms that the SIEM system receives the adjusted records and notes the time of the change. The ISSO reviews each change to confirm that an authorized individual made it on time. Evidence: the logging change record, the SIEM system history of configuration edits, and the ISSO review notes.

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.