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 low 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(3) — Limit Personally Identifiable Information Elements
• AU-04 — Audit Log Storage Capacity
• AU-05 — Response to Audit Logging Process Failures
• AU-06 — Audit Record Review, Analysis, and Reporting
• AU-08 — Time Stamps
• AU-09 — Protection of Audit Information
• AU-10 — Non-repudiation
• AU-11 — Audit Record Retention
• AU-12 — Audit Record Generation
• AU-16 — Cross-organizational Audit Logging

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 every 3 years 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 3 years, 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 / HVA overlay 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(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-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)

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-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 / HVA overlay 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-10 — Non-repudiation #

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

Requirement:

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

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, [AU-10 parameter 1 — to be defined].

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-16 — Cross-organizational Audit Logging #

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

Requirement:

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.

Implementation guidance:

When a High Value Asset or other system sends audit information to an outside organization, or receives it from one, the System Owner must agree with that organization on how they share it. The agreement must use [AU-16 parameter 1 — to be defined] and cover [AU-16 parameter 2 — to be defined]. Each side must record the identity behind each request at the system where the request starts. Systems further along the path must record that the request came from that authorized person or process. The System Owner must write these terms into the information exchange agreement for the connection. The agreement must also say how each side protects the shared logs and how fast it hands them over for an incident. The ISSO must confirm that shared logs still meet the retention and timestamp rules in this policy, as OMB M-26-14 requires.

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.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.
• 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.