By Logging Under M-26-14: A Roadmap for CISOs, ISSMs and Operations Leads
OMB M-26-14 replaced the M-21-31 logging tiers in May 2026, and every agency is re-planning. This roadmap covers what changed, the controls logging evidences, the decisions that stay with the government, and the contract terms that keep a logging and monitoring effort on schedule.
For five years, federal logging was measured against OMB M-21-31's event-logging tiers. Many agencies never fully reached them, and most sized their log platforms and storage to them. In May 2026, OMB M-26-14 (opens in a new tab) replaced that memo. Agencies now owe updated logging plans built on a different model, and the CISO, the ISSM and the operations lead all have a stake in getting it right.
This roadmap is for the people who have to write that plan, implement it and defend it.
What Changed
| Before (M-21-31) | Now (M-26-14) |
|---|---|
| Event-logging maturity tiers with prescribed log types and retention periods | A risk-based model built around continuous event monitoring and threat hunting and investigation objectives |
| A single retention rule applied broadly | Retention and collection decisions tied to risk and to what the logs are used for |
| Tier attainment as the measure | A maturity model agencies plan and report against |
CISA has published a Logging Reference Architecture (opens in a new tab) to guide which logs to collect and how to architect collection. Agency logging plans build on both documents.
Two practical consequences follow. First, an agency that sized storage to the old retention periods may now be paying for data that its risk-based plan does not require, and the plan is the place to decide that. Second, an agency that never met the old tiers still has the same gaps; they now appear as gaps against the new model. In both cases the inventory of what is actually collected, where it is stored and what it costs is the starting point, because a plan written without it describes an environment the agency does not have.
The Controls Logging Evidences
Logging and monitoring produce evidence for a defined set of NIST SP 800-53 Rev. 5 controls. Each should have an owner and a current artifact.
| Control | What the program office should be able to show |
|---|---|
| AU-2 Event logging | The source matrix: which events are logged, from which systems, and why |
| AU-3 Content of audit records | Records that carry the fields investigation needs |
| AU-6 Audit record review | Who reviews what, how often, and with which tools |
| AU-9 Protection of audit information | Logs stored where the systems that produce them cannot alter them |
| AU-11 Audit record retention | Retention periods, with the risk decision that set them |
| AU-12 Audit record generation | Configuration evidence that systems generate the required records |
| CA-7 Continuous monitoring | Monitoring data and reporting that feed the continuous monitoring program |
| SI-4 System monitoring | Alerting with documented thresholds, owners and escalation paths |
The organization-defined parameters in AU-11 and AU-6, such as retention periods and review frequency, should now reflect the agency's M-26-14 plan. A policy that still cites the M-21-31 periods is out of date.
What Stays With the Government
Three decisions belong to the agency, and the plan should name who makes each:
- Retention and collection. Which logs to keep, for how long and in which tier is a risk decision for the CISO, informed by cost and by what investigators need. A contractor can size the options and show their cost; it should not make the call.
- Plan approval and reporting. The logging plan and progress against the maturity model are agency deliverables. Engineering support helps produce them; it does not own them.
- Escalation to incident response. When monitoring surfaces a likely compromise, the decision to open an incident belongs to the agency's security operations leadership.
The accurate claim for any proposal or status brief follows from this. A logging and monitoring effort "implements the collection, retention and alerting the agency's logging plan requires and produces evidence for the AU, CA-7 and SI-4 controls." It does not "achieve M-26-14 compliance," because the agency's plan and reporting do that.
Building the Plan on What Exists
Most agencies already own the tools they need. The faster route to a credible plan starts with an inventory: every monitoring and logging tool, what it collects, what it costs and when it renews; a coverage map against the asset inventory; and a gap list against the new objectives. That inventory usually shows overlapping tools and a few blind spots, and it turns the plan from a policy document into one the agency can implement.
Where the environment is in the cloud, centralized collection belongs in the foundation: a dedicated logging account that workloads write to but cannot alter. A landing zone built as code (opens in a new tab) is where that pattern is set once rather than rebuilt for every program.
Cloud and SaaS Logs
Cloud services add log sources that on-premises plans never listed: control-plane activity, identity provider events, storage access logs and network flow logs. Many are off by default or retained only briefly by the provider. A plan written for the data center misses them, and they are often the first records an investigator asks for after a cloud incident.
SaaS platforms add a contractual dimension. Whether the agency can export the logs it needs, in what format and for how long, depends on the service's terms, so the plan should list each SaaS service, the logs available from it, and how they reach the agency's own storage.
Questions to Settle Early
- Which systems are in scope for the updated plan, and does the asset inventory list all of them?
- Which log sources does the security team actually use in investigations today?
- Where are logs stored now, for how long, and what does each tier cost?
- Which monitoring and logging contracts renew in the next 12 months?
- Who reviews alerts after hours, and is that written down?
- Which logs leave the agency's control, for example in a SaaS platform, and under what terms?
- Which monitoring outputs does the continuous monitoring program already rely on, and who maintains them?
SOW Terms That Hold the Schedule
A logging and monitoring statement of work protects the schedule by making dependencies explicit:
- A locked source matrix as an appendix, with unit prices for additional sources.
- Government-furnished items with dates: accounts and network access, administrator access to existing tools, the asset inventory, change board slots, firewall changes and ISSO approval of agents and collectors.
- A clock-stop when access or approvals slip, reported weekly.
- Explicit exclusions: security detection content, alert triage, threat hunting, incident response and platform licenses.
- A measured ingest baseline before any implementation price is final.
- Dashboard limits per audience, with a change path.
- Firm fixed price for the assessment and for implementation against the locked matrix.
Sequencing the Work
A practical order for a program office: confirm the systems in scope and the inventory; run a readiness assessment that maps tools, coverage and gaps against the new objectives; record the agency's retention and collection decisions; then implement in phases, starting with the sources that serve the most important objectives and the tools whose contracts end first. The cost of consolidating the cloud foundation once (opens in a new tab) is a useful comparison for budget offices weighing the same build-once logic for logging.
Avalon's Enterprise Monitoring service starts with a fixed-price readiness assessment that maps your tools, coverage and logging gaps against your M-26-14 plan, then implements the collection, retention and alerting the plan requires, with evidence for the AU, CA-7 and SI-4 controls.
