Audit and Accountability Policy

Approval #

Revision History #

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

1. Purpose and Scope #

In this policy, the CISO sets the Organization’s requirements for audit and accountability in every information system that the Organization operates or that others operate for it. The CISO issues the policy under these authorities:

• The Federal Information Security Modernization Act (FISMA) of 2014.
• National Institute of Standards and Technology (NIST) Special Publication 800-53 Revision 5.
• Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource.
• The OMB memoranda and Executive Orders that apply.

The Organization also uses this policy to carry out the NIST Cybersecurity Framework (CSF) 2.0, which Executive Order 13800 and OMB Circular A-130 require.

1.1 Program Objectives #

This policy covers what the Organization logs and how it protects, keeps, and uses the records. OMB M-26-14 replaced the M-21-31 logging tiers with two objectives: continuous event monitoring, and threat hunting, investigation, response, and forensics. It backs those objectives with a minimum logging baseline and a maturity model. The Organization must log the required events, make the logs readily available to the top-level security operations center, protect log integrity, and synchronize time across the enterprise. Logs must stay searchable for at least 6 months and retrievable for at least 12 months. The Organization builds its logging to the Cybersecurity and Infrastructure Security Agency (CISA) Logging Reference Architecture, because the audit trail decides how fast it can respond to an incident.

This policy applies to everyone in the program: executives who accept risk, System Owners who fund the controls, security officers who run them, and every user. By following it, the Organization meets its FISMA obligations for this control family and shows its maturity in the annual Inspector General (IG) FISMA evaluation. The Organization’s target is Level 4 (Managed and Measurable). The CISO tracks progress with the performance measures and the improvement commitments later in this policy.

1.2 CSF 2.0 Alignment #

The controls in this policy support these CSF 2.0 categories:

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

These categories fall under the Detect, Respond function(s) of CSF 2.0. The Organization’s CSF 2.0 Profile maps each category to the NIST SP 800-53 controls in this policy.

This policy covers every audit and accountability control in the high baseline of FIPS 200 and NIST SP 800-53B:

• AU-01 — Policy and Procedures
• AU-02 — Event Logging
• AU-03 — Content of Audit Records
• AU-03(1) — Additional Audit Information
• AU-03(3) — Limit Personally Identifiable Information Elements
• AU-04 — Audit Log Storage Capacity
• AU-05 — Response to Audit Logging Process Failures
• AU-05(1) — Storage Capacity Warning
• AU-05(2) — Real-time Alerts
• AU-06 — Audit Record Review, Analysis, and Reporting
• AU-06(1) — Automated Process Integration
• AU-06(3) — Correlate Audit Record Repositories
• AU-06(4) — Central Review and Analysis
• AU-06(5) — Integrated Analysis of Audit Records
• AU-06(6) — Correlation with Physical Monitoring
• AU-06(7) — Permitted Actions
• AU-07 — Audit Record Reduction and Report Generation
• AU-07(1) — Automatic Processing
• AU-08 — Time Stamps
• AU-09 — Protection of Audit Information
• AU-09(2) — Store on Separate Physical Systems or Components
• AU-09(3) — Cryptographic Protection
• AU-09(4) — Access by Subset of Privileged Users
• AU-10 — Non-repudiation
• AU-11 — Audit Record Retention
• AU-12 — Audit Record Generation
• AU-12(1) — System-wide and Time-correlated Audit Trail
• AU-12(3) — Changes by Authorized Individuals

2. Authority and References #

The CISO issues this policy under the authority of:

• FISMA 2014 (44 U.S.C. § 3551 et seq.) — Statutory mandate for federal information security programs
• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
• OMB Circular A-130 — Managing Information as a Strategic Resource
• OMB Circular A-123 — Management’s Responsibility for Internal Control (revised March 10, 2026)
• NIST CSF 2.0 — Cybersecurity Framework (mandated by EO 13800 and OMB Circular A-130)
• EO 13800 — Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure
• OMB M-26-14: Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats, May 22, 2026.
• CISA Logging Reference Architecture (companion to OMB M-26-14), August 20, 2026.
• OMB M-22-01: Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Systems through Endpoint Detection and Response (EDR), October 8, 2021.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• 36 CFR Part 1236: Electronic Records Management, current text.
• NARA General Records Schedule 6.1: Email and Other Electronic Messages Managed under a Capstone Approach, January 2023.

2.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 in the Policy section.

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)

3. Policy #

The Organization must implement and maintain its audit and accountability controls to meet the following requirements:

AU-01 — Policy and Procedures #

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

Requirement:

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].

Implementation guidance:

The Organization must keep an audit and accountability policy and the procedures that put it into practice. The CISO is the designated official who manages the development, documentation, and distribution of both documents. The CISO’s office distributes them to the Authorizing Official, System Owners, Application Owners, Information System Security Officers (ISSOs), and the stakeholders who work under them. The CISO must review and update each document at least every year, and sooner after a major incident or a major change to applicable policy. The policy must state the obligations the Organization answers for outside the agency. These include the two OMB M-26-14 logging objectives: continuous event monitoring, and threat hunting, investigation, response, and forensics. They also include the minimum logging baseline and maturity model that memorandum sets, the CISA Logging Reference Architecture it references, and the retention floor of six months searchable and twelve months retrievable. The Organization’s own retention of 12 months active and 18 months cold exceeds that floor.

AU-02 — Event Logging #

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

Requirement:

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.

Implementation guidance:

Every system must log the events the OMB M-26-14 minimum baseline requires. These events include the identity behind each operation, and the source and destination network addresses with their protocols, ports, and session attributes. They include access to objects and data, and any change to or destruction of them. They include privilege changes, additions and removals of endpoints and infrastructure, alerts from security tools, known indicators of compromise, and anomalous system or user activity. The records must hold enough detail to size an incident and trace its attack path from initial access through lateral movement. The requirement covers identity services, privileged use, email, network devices, operating systems, cloud environments, endpoints, databases, applications, virtualization, mobile devices, and containers. System Owners must document what their system can log, what it does log, and why that selection is enough to reconstruct an incident afterward. ISSOs must coordinate event selections with the Security Operations Center (SOC) and the other offices that depend on audit data. Logged events must stream to the security information and event management (SIEM) system in near real time. System Owners must review the selections every year. They must also review them whenever OMB or CISA changes the logging baseline or maturity model, or the system’s threat environment changes. A logging gap found during an incident is a finding against this policy.

AU-03 — Content of Audit Records #

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

Requirement:

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.

Implementation guidance:

Every audit record must capture what happened, when it happened, where it happened, the source that produced it, how it ended, and the identity of the user or process behind it. System Owners must make sure their components produce records complete enough for an analyst to reconstruct the activity without access to the machine. This meets the OMB M-26-14 expectation that logs carry the detail that threat hunting, investigation, response, and forensics need. ISSOs must verify record completeness when a source onboards to the SIEM system and whenever a system change alters a log format. Where record content could expose information about individuals beyond the audit purpose, the ISSO must limit the content. Completeness does not permit over-collection.

AU-03(1) — Additional Audit Information #

Baselines: Moderate / High

Requirement:

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.

Implementation guidance:

Audit records must carry the added fields that make cross-source analysis possible, as OMB M-26-14 and the CISA Logging Reference Architecture require. The fields are accurate timestamps, event status codes, device and session identifiers, source and destination addresses, response times, and, where applicable, the user and the command that ran. Sources must structure log data as key-value pairs wherever the platform permits. Each event type must carry a unique event identifier, so an analyst can follow one action across systems. System Owners must configure their sources to this standard. Where a source cannot meet it, the System Owner must track the exception and must not waive it.

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

Baselines: Privacy

Requirement:

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].

Implementation guidance:

System Owners must limit the personally identifiable information (PII) written to audit records to [AU-03(3) parameter 1 — to be defined]. The ISSO must check each system’s audit settings against the privacy risk assessment before the system enters service and after any change to its logging settings. Some event logs that OMB M-26-14 requires may capture PII beyond these elements. In that case, the System Owner must mask or drop the extra fields before the events reach the SIEM system. The Senior Agency Official for Privacy (SAOP) must approve any request to log an additional PII element. The SAOP must also confirm that a system of records notice covers that element before logging begins.

AU-04 — Audit Log Storage Capacity #

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

Requirement:

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

Implementation guidance:

The Organization must allocate audit log storage for at least [AU-04 parameter 1 — to be defined] of active, rapidly searchable data and a further 18 months in cold storage, for 30 months of coverage in total. This is the Organization’s own retention parameter, and it exceeds the OMB M-26-14 floor of six months searchable and [AU-04 parameter 1 — to be defined] retrievable. The SIEM system is the central repository, and the SOC must keep its retention configuration matched to those periods. System Owners must declare the expected log volume when a system onboards, so the SOC can plan central capacity in advance. The SOC must monitor consumption against capacity and must act before the storage runs out. Losing audit data to a full disk is a preventable failure. Growth in event volume is a planning input, and the Organization never accepts it as a reason to shorten retention.

AU-05 — Response to Audit Logging Process Failures #

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

Requirement:

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.

Implementation guidance:

Every system must detect a failure in its audit logging process, including a failed agent, a broken transport, storage exhaustion, or a stalled pipeline. The system must alert the System/Application Owner, the ISSO, and the System/Application Administrators in near real time. System/Application Administrators must build the alerting into the pipeline, so detection does not depend on a person noticing a quiet dashboard. Where the Agency defines additional response actions for a failure type, the administrators must carry them out as defined. The Organization treats a logging failure that comes to light only during a later investigation as a security incident. The SOC must assess every outage to determine what the Organization could not see while it lasted.

AU-05(1) — Storage Capacity Warning #

Baselines: High

Requirement:

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.

Implementation guidance:

Each system must warn [AU-05(1) parameter 1 — to be defined] when audit log storage fills. The warning must arrive within [AU-05(1) parameter 2 — to be defined]. It must trigger when used storage reaches 75%, or one month before expected negative impact of the repository’s maximum capacity. System Owners must configure these warnings for every log repository their system uses. As OMB M-26-14 requires, logs must stay searchable for the security operations center, so storage must not run out without notice.

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

Baselines: High

Requirement:

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.

Implementation guidance:

Each system must send an alert to service provider personnel with authority to address failed audit events when audit failure events requiring real-time alerts, as defined by organization audit policy occur. The alert must arrive within real-time. System Owners must configure these alerts for every system that sends logs to the SIEM system. As OMB M-26-14 directs, the Organization must generate automated alerts for logging events. The ISSO must track each alert until logging is restored.

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

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

Requirement:

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.

Implementation guidance:

The SOC must review and analyze audit records every week for moderate-impact and high-impact systems and every week for low-impact systems. At a minimum, the review must cover system and service starts and stops, network connection changes and failures, and changes or attempted changes to security settings. It must also cover logon activity and what followed it, account and privilege changes, use of privileged accounts, and application authentication, configuration, and transaction anomalies. The SOC must report findings to the System/Application Owner, the ISSO, and the System/Application Administrators. Those recipients own the response. When law enforcement, an intelligence source, or another credible source reports a higher threat, the CISO must direct deeper and more frequent analysis. The CISO must not wait for the next cycle. High value assets carry the enhanced review expectations of the CISA HVA Control Overlay. The SOC must not reduce their coverage.

AU-06(1) — Automated Process Integration #

Baselines: Moderate / High

Requirement:

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

Implementation guidance:

Audit record review, analysis, and reporting must run through one integrated, automated pipeline. Manual review cannot keep up with the event volume the enterprise produces. The SIEM system is the one enterprise system for collection, correlation, alerting, and reporting. The SOC must keep the SIEM system able to feed the Agency-wide log aggregation capability. The CISO must make sure that incident response, continuous monitoring, and Inspector General audit support all draw on this integrated capability, and not on extracts assembled by hand after a question arrives.

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

Baselines: Moderate / High

Requirement:

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

Implementation guidance:

The SOC must analyze and correlate audit records across the Organization’s repositories, including endpoint telemetry, cloud platform logs, and identity, application, and infrastructure sources. An event that looks harmless in one repository can prove an attack when read beside an event from another. The SIEM system is the correlation point, where telemetry from the EDR tools meets the cloud platform and application logs. For high value assets, the CISA HVA Control Overlay requires cross-repository correlation. The SOC must treat correlated findings as one case.

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

Baselines: High

Requirement:

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

Implementation guidance:

The Organization must review and analyze audit records from all system components in one central place. The SIEM system is that central place. System Owners must send audit records from every component of their systems to it. The security operations center must review and analyze those records there. Per OMB M-26-14, logs must be readily available to the top-level security operations center.

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

Baselines: High

Requirement:

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.

Implementation guidance:

The Organization must combine audit record analysis with analysis of vulnerability scanning information; performance data; information system monitoring information; penetration test data; {{ insert: param, au-06.05_odp.02 }}. The security operations center must also include [AU-06(5) parameter 2 — to be defined] where defined. Analysts must look at these sources together to spot activity that no single source reveals. System Owners must make sure their scan results, performance data, and monitoring data reach the SIEM system. The security operations center must use this combined view during alert review and incident analysis.

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

Baselines: High

Requirement:

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.

Implementation guidance:

The security operations center must compare audit records with physical access records to find suspicious or unusual activity. Facility badge and entry records must be available for this comparison. System Owners must make sure their systems’ audit records identify the user and the time of each logon. The ISSO must use the combined records when investigating an account that shows unusual behavior.

AU-06(7) — Permitted Actions #

Baselines: High

Requirement:

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

Implementation guidance:

The Organization must define the allowed actions on audit records for each information system process; role; user that reviews, analyzes, or reports on them. Allowed actions include read, write, and delete rights. Most reviewers must have read access only. System Owners must document these rights for their systems. Account managers must grant them through defined roles in the SIEM system and the cloud platform log stores. The Information System Security Officer (ISSO) must review the assignments during account reviews.

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)

Requirement:

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.

Implementation guidance:

The Organization must provide an audit record reduction and report generation capability. The capability must reduce bulk log data to summaries an analyst can work with, and must produce reports on demand for investigations, assessments, and Inspector General requests. Reduction and reporting must never change the underlying record. Summaries and reports are views of intact source data, and the original content and its time sequence stay exactly as captured. The SIEM system provides this capability for the enterprise. System Owners must make sure their systems’ records arrive in a form the capability can process. A report has no value as evidence unless the SOC can trace it back to unaltered records, so the Organization does not produce such reports.

AU-07(1) — Automatic Processing #

Baselines: Moderate / High

Requirement:

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].

Implementation guidance:

The audit reporting capability must support processing, sorting, and searching records by the criteria investigations use. Those criteria are the identities of individuals, event types, locations, dates and times, the system resources involved, Internet Protocol (IP) addresses, and the information objects accessed. The SOC must keep these fields searchable across every onboarded source. An analyst must be able to go from a question to the matching records without engineering work in between. An investigation that cannot filter records by user, time, and address takes too long.

AU-08 — Time Stamps #

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

Requirement:

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.

Implementation guidance:

Every system must stamp its audit records using its internal system clocks. System/Application Administrators must synchronize those clocks so timestamps are accurate to within 10 milliseconds. Timestamps must use Coordinated Universal Time (UTC) or carry a fixed, recorded offset from it, so records from different components line up without interpretation. System/Application Administrators must configure time synchronization on every component they operate. ISSOs must verify timestamp accuracy and format when a source onboards and when someone suspects drift. Records that disagree about time cannot support correlation, and a mis-timed record breaks the sequence an investigation depends on. Administrators must correct a drift finding with the urgency of a security defect.

AU-09 — Protection of Audit Information #

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

Requirement:

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.

Implementation guidance:

The Organization must protect audit information and the tools that manage logging from unauthorized access, modification, and deletion. Audit information includes the records, the log settings, and the reports that come from them. Logs are among the first things a capable intruder edits. The SOC must limit access to the SIEM system workspace and the underlying log stores to authorized roles, and the workspace must log every change to the logging configuration. When a system detects unauthorized access to audit information or tampering with it, the system must alert the System/Application Owner, the ISSO, and the System/Application Administrators. The SOC must treat the event as hostile until an investigation shows otherwise. An organization that cannot trust its own logs has nothing to show an assessor or a court.

AU-09(2) — Store on Separate Physical Systems or Components #

Baselines: High

Requirement:

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.

Implementation guidance:

Each system must send its audit records at least weekly to a log repository that runs on separate hardware from the system that produced them. A compromise of the audited system must not give the intruder control of its logs. System Owners must configure forwarding to the SIEM system for every component. The security operations center must keep the central repository apart from the systems it monitors. The ISSO must confirm that forwarding works after each system change.

AU-09(3) — Cryptographic Protection #

Baselines: High

Requirement:

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

Implementation guidance:

The Organization must use cryptography to protect the integrity of audit records and the tools that manage them. Any change to a stored record or a logging tool must be detectable. System Owners must make sure their log stores use the integrity protections that their platforms provide, such as signed hashes or write-once storage. The ISSO must verify that these protections remain on. Per the CISA Logging Reference Architecture, the Organization must protect the integrity of sensitive log data.

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

Baselines: Moderate / High

Requirement:

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

Implementation guidance:

The people a log records must not control that log. Only privileged accounts whose audit duties are separate from their holders’ other administrative responsibilities may manage audit logging functionality, including retention, analytics rules, and connector and source configuration. No administrator may hold both the ability to act on a system and the ability to rewrite the record of that action. The ISSO must concur on every grant of audit-management access and must confirm that the separation still holds when a holder’s duties change.

AU-10 — Non-repudiation #

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

Requirement:

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.

Implementation guidance:

The Organization must keep audit evidence that ties each covered action to the person who performed it, or to the process acting for that person. Each record must use the actor’s own authenticated identity, never a shared or generic account. System Owners must configure each system to capture the following actions with the actor’s identity attached, minimum actions including the addition, modification, deletion, approval, sending, or receiving of data.

System Owners must protect these records from change or deletion and forward them to the SIEM system. Records must stay searchable for at least 6 months and retrievable for at least 12 months, per OMB M-26-14. Each record must carry an accurate timestamp from the Organization’s designated time source. The ISSO must confirm that each system meets this requirement before authorization and after each major change. The CISO owns this requirement and approves any exception in writing.

AU-11 — Audit Record Retention #

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

Requirement:

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.

Implementation guidance:

The Organization must retain audit records for a time period in compliance with OMB M-26-14 in active, rapidly searchable storage and a further 18 months in cold storage, for 30 months in total. This is the Organization’s own retention parameter. It exceeds the OMB M-26-14 floor of six months searchable and a time period in compliance with OMB M-26-14 retrievable, and it is consistent with the Organization’s records retention obligations. Retention lets the Organization investigate after the fact and answer legal and regulatory demands that it cannot schedule. System Owners must not dispose of audit records early for cost or convenience. A legal hold or an open investigation suspends disposal of the affected records. Release from a hold must be a documented decision. When the retention period ends, disposal must follow the records schedule and must leave a record of its own.

AU-12 — Audit Record Generation #

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

Requirement:

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.

Implementation guidance:

System/Application Administrators must enable audit record generation on every system component, including servers, endpoints, network devices, cloud services, and applications. A sampled subset is not enough. Each component must be able to produce records for the event types its system must cover. The System/Application Owner selects the event types each component logs, guided by applicable OMB direction. The records must carry the full content this policy requires of audit records. ISSOs must verify that no component enters service, or stays in service, without logging. A component that cannot log is an accepted risk only when the Authorizing Official has accepted that risk in writing. An unlogged component found in operation is a deficiency, and the System/Application Owner must correct it.

AU-12(1) — System-wide and Time-correlated Audit Trail #

Baselines: High

Requirement:

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].

Implementation guidance:

The Organization must combine audit records from all network, data storage, and computing devices into one system-wide audit trail in the SIEM system. Timestamps across that trail must agree to within [AU-12(1) parameter 2 — to be defined]. System Owners must synchronize every component to the Organization’s designated time source, per OMB M-26-14. The ISSO must verify clock accuracy and log source coverage for each system. The CISO must approve any exception.

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

Baselines: High

Requirement:

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].

Implementation guidance:

The Organization must give service provider-defined individuals or roles with audit configuration responsibilities the ability to change the logging performed on all network, data storage, and computing devices. Logging changes must respond to selectable event criteria that include[AU-12(3) parameter 3 — to be defined]. Each change must take effect within [AU-12(3) parameter 4 — to be defined] of the decision to make it. Only authorized individuals must make these changes. The ISSO must review each change.

4. Roles and Responsibilities #

These roles apply across this policy. Each System Owner records the system-specific assignments in the system’s System Security and Privacy Plan (SSPP).

5. Performance Measurement #

The CISO manages this policy with the measures below, which meet the IG FISMA maturity model’s Level 4 (Managed and Measurable) criteria. The CISO collects and trends the measures and reports them to the CIO and the Authorizing Officials. When a measure moves away from its target, the CISO starts corrective action through the plan of action and milestones (POA&M) process.

The CISO keeps the measurement data for the annual IG FISMA evaluation and for trend analysis across reporting periods.

6. Compliance and Enforcement #

Every employee, contractor, and other user with access to an information system that the Organization operates, or that others operate for it, must comply with this policy. The CISO records each case of non-compliance as a finding in the Organization’s continuous monitoring program. The ISSO tracks the finding to resolution as a POA&M item, as OMB Circular A-130 and NIST SP 800-37 Rev. 2 describe.

A violation of this policy can lead to suspension of system access, withdrawal of the system’s authorization to operate (ATO), and administrative or disciplinary action under applicable law, regulation, and human capital policy.

The Inspector General assesses the maturity of audit and accountability controls each year through the IG FISMA reporting metrics. The target maturity level for this policy area is Level 4: Managed and Measurable.

7. Continuous Improvement #

Level 4 is the minimum the Organization aims for. To meet the IG FISMA maturity model’s Level 5 (Optimized) criteria, the CISO improves audit and accountability through these commitments:

1. Review the performance measures in this document at least annually; where a measure has met its target for four consecutive periods, tighten the target or replace the measure with a more demanding indicator.
2. Conduct an annual effectiveness review of this policy area using IG FISMA audit results, assessment findings, incident data, and metric trends; document resulting changes in the revision history.
3. Feed lessons learned from incidents, assessments, and exercises into updates of this document and its procedures within 90 days of the triggering event.
4. Benchmark against the IG FISMA maturity model annually and maintain a documented plan to reach and sustain Level 4 (Managed and Measurable), with a roadmap toward Level 5 (Optimized).
5. Increase SIEM detection coverage against a recognized threat framework (e.g., MITRE ATT&CK) and measure coverage growth quarterly.
6. Automate log source onboarding and heartbeat monitoring so new systems begin forwarding required events without manual configuration.

8. Exceptions and Waivers #

The CISO may grant an exception to this policy only when compliance is not technically feasible or would harm the mission. To request one, the System Owner sends the CISO a written request that includes:

1. A business justification and a risk assessment.
2. Compensating controls that reduce the risk the exception creates, following the NIST SP 800-53B guidance on compensating controls.
3. A proposed end date no more than one year away.

The CISO decides each request in coordination with the Authorizing Official. An exception that involves privacy risk also needs the agreement of the Senior Agency Official for Privacy (SAOP). The CISO re-evaluates each exception when it comes up for renewal. The System Owner records each approved exception in the system’s SSPP, and the ISSO tracks it as a POA&M item.

9. References #

These are the sources this document cites, with a link to each official text.

• 36 CFR Part 1236: Electronic Records Management, current text.
• CISA High Value Asset (HVA) Control Overlay v1.0, November 1, 2017.
• CISA Logging Reference Architecture (companion to OMB M-26-14), August 20, 2026.
• CISA Zero Trust Maturity Model, April 11, 2023.
• Executive Order 13800: Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, May 11, 2017.
• 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.
• FIPS 200: Minimum Security Requirements for Federal Information and Information Systems, March 2006.
• NARA General Records Schedule 6.1: Email and Other Electronic Messages Managed under a Capstone Approach, January 2023.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, December 2018.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• NIST SP 800-53B: Control Baselines for Information Systems and Organizations, September 2020.
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025.
• OMB Circular A-123: Management’s Responsibility for Internal Control, March 10, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• Superseded source, kept for its history: OMB M-21-31: Improving the Federal Government’s Investigative and Remediation Capabilities Related to Cybersecurity Incidents, August 27, 2021. Replaced by OMB M-26-14.
• 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.