by James Scobey, S2i2 CTO
When OMB issued Memorandum M-21-31 in August 2021, I was a federal CISO. The Sunburst supply-chain compromise was still fresh, the investigative gaps it exposed were embarrassing, and the policy response was the right impulse: collect more, retain longer, give responders the breadcrumbs they need. What I learned over the years that followed is that the impulse and the execution are different problems. M-21-31 raised the floor on federal logging. It also produced storage bills agencies could not sustain, compliance theater that confused collection with detection, and a generation of SIEM deployments that hoarded everything and surfaced nothing.
OMB’s new Memorandum M-26-14, issued May 22 by Director Russell Vought, rescinds M-21-31 and replaces it with a risk-based, outcome-oriented logging framework. Reading it through the lens of someone who lived the previous regime, my reaction is: this is the right correction, with caveats worth naming up front. Where M-21-31 Strained
M-21-31 was a maximalist policy written in a moment that called for maximalism. The Event Logging Tier model (EL0 through EL3) imposed uniform collection requirements across enormously different agencies. Whether you ran a 30,000-endpoint enterprise or a small regulatory shop, you owed the same tier-based collection set with the same retention windows: 12 months hot, 18 months cold, 30 months total. The intent was forensic completeness. The reality was that agencies hit the policy’s collection mandates and then sat on terabytes (sometimes petabytes) of unindexed, unalerted log data nobody had the analyst capacity to actually use.
The cost curve was brutal. Hot-storage SIEM ingest at scale costs roughly $1 to $4 per gigabyte per day depending on platform and contract. A medium-sized cabinet agency could easily generate 5 to 20 terabytes per day at full M-21-31 collection scope. Multiply that by 12 months and add the cold-storage tail; the math became unsustainable before most agencies got to EL2. I watched colleagues across the federal CISO community quietly de-scope collection just to make the budget work, sometimes with the chief financial officer’s blessing and sometimes not. That is not a story of bad CISO leadership; it is a story of a policy that asked agencies to do something the federal budget process was not going to fund.
Beyond cost, M-21-31 had three structural problems. First, it confused collection with detection. Tier compliance measured what you ingested, not whether your SOC could actually act on it. Second, it ignored operational technology and Internet of Things infrastructure almost entirely. HVAC controllers, badging systems, building automation, and the long tail of network-attached devices fell into a policy blind spot that adversaries did not. Third, the retention windows collided with records-management schedules in ways that varied by agency and created compliance puzzles nobody had been chartered to solve.
The Right Question M-26-14 reframes the policy around two outcome objectives: Continuous Event Monitoring (CEM) and Threat Hunting, Investigation, Response, and Forensics (THIRF). CEM is the real-time SOC mission: ingest, detect, alert, respond. THIRF is the after-incident mission: hot and cold log retrieval, attack reconstruction, forensic analysis. The shift from tier-based collection to outcome-based capability matters because it asks the right question. Instead of “are you collecting the prescribed log types?”, agencies now have to answer “can you actually detect, respond, and forensically reconstruct?” Layered on top of the CEM and THIRF objectives is a maturity model with five levels (Ineffective, Initial, Intermediate, Advanced, Optimal) scored across five elements: Inventory Visibility, Collection Coverage, Collection Operations, Data Retention, and Log Management. Overall maturity is set by the lowest watermark, which means you cannot Advanced-score your way around a weak link. That scoring philosophy is correct: in security, your real posture is the worst of your components, not the average. The retention requirements have come down meaningfully: 6 months actively searchable, 12 months retrievable. That is a deliberate reset from M-21-31’s 30-month total window, and I think it is defensible for most use cases. CISA will publish a Logging Reference Architecture (LRA) within 90 days that becomes the actual implementation manual. Agency Logging Plans are due within 90 days of the LRA. Agencies are expected to hit Level 1 within 120 days of the LRA, Level 2 within 180 days, and Level 3 within 320 days.
What the Memo Gets Right The outcome-based framing is the biggest win. CEM and THIRF map cleanly to how SOC teams actually organize their work; M-21-31’s tier model never did. A CISO can stand up a budget conversation around CEM and THIRF capability building in a way that resonates with both the program side (mission detection coverage) and the CFO (capability-tied spend rather than open-ended storage growth). That is the kind of policy framing that survives a budget review. The risk-based prioritization is honest. M-26-14 explicitly tells agencies to prioritize High Value Assets and High Impact Systems first. Federal CISOs have always done some version of this implicitly because we have to; making it explicit lets us defend prioritization decisions on policy grounds rather than apologizing for them. The same is true of the maturity model’s progression. Nobody builds enterprise logging capability in a single budget cycle, and a policy that pretends otherwise produces compliance theater rather than security outcomes. The explicit acknowledgment of Internet of Things and operational technology is overdue. Building systems, manufacturing controls, badging infrastructure, and the long tail of OT devices are real attack surface that previous policy guidance treated as out of scope by omission. M-26-14 directs the LRA to cover IoT and OT including devices without native logging. That last part matters: a meaningful share of OT cannot generate its own logs, and the policy now obliges agencies to think about network-level visibility as a substitute when device-level logging is not possible.
The architectural flexibility is welcome. M-26-14 allows centralized log storage, centralized access over federated storage, or a hybrid. Some agencies have the SOC topology and bandwidth to centralize everything; others (particularly the geographically distributed ones) have always needed federated approaches and were quietly working around the M-21-31 centralization defaults. Letting agencies design to their topology rather than reverse-engineering compliance is a meaningful improvement. Two other points deserve credit. The Zero Trust alignment resolves a real tension where agencies were running parallel compliance tracks against CISA’s Zero Trust Maturity Model and OMB’s logging guidance, with the two not always agreeing on what mature visibility looked like. And the explicit acknowledgment that AI and machine learning are part of the detection toolkit reflects operational reality: no human-staffed SOC can manually process modern federal log volumes. The policy now says so out loud, which gives CISOs cover to invest in detection automation as a first-class capability rather than a side project.
Where I’d Push Back The Logging Reference Architecture is not published yet. Agencies have 90 days to wait, then 90 days to plan, then 120 days to hit Level 1. The first 90-day window is when smart agencies will begin foundational work (inventory, time-sync, encryption, HVA identification), but without the LRA in hand, some of that work is necessarily speculative. The agencies that guess right will look prescient; the ones that guess wrong will have to redo work on a compressed schedule. CISA needs to land the LRA on time and substantively, or the back half of the implementation timeline becomes unworkable.
The lowest-watermark scoring is correct in principle but unforgiving in practice. An agency at Advanced on four elements and Initial on the fifth is reported as Initial overall. From a security-posture standpoint that is the right framing; from a measurement-and-reporting standpoint, it means agencies will be incentivized to overinvest in their weakest element rather than to optimize across the portfolio. Both behaviors have failure modes. CISA and OMB should be prepared to publish supplementary metrics that show component-level progress, not just composite scores.
The retention reduction has long-dwell implications I would want CISOs to think about carefully. Median nation-state adversary dwell time runs over a year in many published incident reports; some campaigns span multiple years before discovery. Twelve months of retrievable log data lets you reconstruct yesterday’s incident, but not necessarily the 14-month-old initial compromise that is still resident in the environment. That is a real tradeoff. For most agencies the cost-benefit favors the new retention windows, but agencies with credible long-dwell threat models (the financial regulators, the health agencies handling research data, anywhere with foreign-intelligence interest) should consider whether their Agency Logging Plan retains longer than the floor for selected log classes.
The 30-day plan-update window after CISA refreshes the LRA is tight. Federal agencies do not, as a rule, turn cybersecurity plans in 30 days; they turn them in 90 to 120. If CISA refreshes the LRA on any meaningful cadence, the 30-day update obligation will collide with normal change-control processes. Expect agencies to maintain “living” Agency Logging Plans with predefined update procedures so they can hit the deadline. That is a documentation discipline most agencies do not currently have.
Finally, I would flag the cultural risk. “Risk-based” is the right framing for this policy, but it is also the framing that, in less careful hands, becomes cover for budget cuts disguised as prioritization. M-21-31’s retention requirements were too high, and bringing them down is correct; the danger is that the change gets read as “you can do less” rather than “you can do smarter.” If your agency’s first conversation about M-26-14 is about reducing logging spend rather than reallocating it toward CEM and THIRF capability, you have a problem. The memo is a license to be smarter, not smaller.
Practical Implementation Advice For agencies starting the M-26-14 work now, before the LRA lands, there is real work that does not require waiting. Start with the asset inventory. Hardware Asset Management and Software Asset Management coverage is the foundation of every maturity level above Ineffective; you cannot log what you do not know exists. Most agencies have Continuous Diagnostics and Mitigation funded inventory programs that have run for years without being treated as a logging dependency. Reframe the conversation: your logging maturity will be capped at whatever your inventory maturity is.
Identify your High Value Assets and High Impact Systems early and build the logging capability outward from them. This is what the memo wants and it is also what makes the work tractable. An agency with 200 information systems cannot bring all 200 to Advanced maturity in 320 days, but it can bring the 20 that matter most to Advanced and the rest to Intermediate. That sequencing is defensible to auditors and operationally honest about where attention needs to go.
Build the time-sync and encryption foundations now. Network Time Protocol synchronization to U.S. Naval Observatory or NIST traceable sources is a basics-level fix that does not require the LRA. Encryption in transit and at rest for logs is a Level 2 requirement and a non-trivial integration project at scale; start it now. Log hashing for veracity is a Level 3 requirement; the tooling has matured significantly in the last two years, and procurement runways are long enough that you want to be evaluating options in the next quarter. Choose your centralization architecture deliberately. Centralized storage, centralized access over federated storage, and hybrid models each have cost, latency, and resilience profiles that matter. A small agency with one SOC and reasonable bandwidth can run pure centralization. A large geographically distributed agency probably cannot afford to ship every log byte to a central SIEM and is better served by federated indexes with cross-search. The LRA will offer guidance; do not wait for it to start the topology conversation internally. Be honest about IoT and OT now. Most agency inventories under-count these systems by significant margins. Walk the building. Inventory the controllers, the badging systems, the conference-room AV, the manufacturing or laboratory equipment. Identify which have native logging capability and which will require network-level visibility instead. This is uncomfortable work because it tends to surface long-deferred problems, but it is the work that separates a credible Agency Logging Plan from one that gets you to Initial on paper but Ineffective in practice.
Treat detection tuning as a team capability, not a tool purchase. The maturity model’s Collection Operations element scores agencies on whether detections are “routinely evaluated and tuned.” That is a SOC engineering function. If your SOC analysts are heads-down on alert queues with no protected time for detection engineering, you cannot reach Advanced regardless of what tools you buy. The cultural and staffing implications of this are real and worth raising with leadership now.
Plan retention as a tiering exercise. The 6-month searchable / 12-month retrievable floor lets you use cold storage aggressively for the bulk-retention tier. Object-storage costs are an order of magnitude lower than SIEM ingest costs; for most agencies, the right architecture is searchable in the SIEM for current operations, with automated lifecycle policies moving older data to cold object storage, plus a defined replay path to bring cold data back when an investigation demands it. The LRA will likely formalize this pattern, but you can build toward it now.
Engage records management early. M-26-14 explicitly notes that meeting the cybersecurity retention floor does not relieve agencies of obligations under other records schedules. Some log classes have records-management retention requirements longer than 12 months; some have requirements shorter than 12 months in ways that interact awkwardly with cybersecurity use cases. The legal and records-management staff need a seat at the Agency Logging Plan table from the start, not bolted on in month nine.
Final Thoughts M-26-14 asks the right question. M-21-31 asked agencies to collect, and they collected; this memo asks agencies to detect, respond, and reconstruct, which is a meaningfully harder problem and the right one to be measuring. The maturity model gives CISOs a defensible language for talking about progress with leadership, with auditors, and with appropriators. The risk-based prioritization gives them permission to do what they were doing anyway, which is a useful kind of policy alignment.
The execution is where the memo lives or dies. The LRA has to land on time and substantively. CISA has to staff the implementation support function it has committed to providing. Agencies have to resist the cultural pull toward reading “risk-based” as “do less.” If those things go well, this is the policy that finally gets federal logging onto an operationally sustainable footing five years after the SolarWinds reckoning made the problem visible. If they do not, we will be writing another memo by 2031.
For now, the right posture for federal CISOs is to start the foundational work that does not require the LRA, name the tradeoffs honestly with agency leadership, and treat M-26-14 as the license it is to build the logging program you actually wanted to build under M-21-31 but could not afford. The memo is good policy. The work is now ours. If you’d like to learn more about how S2i2 can help, contact us at info@s2i2.com or call us at 1-844-946-7242. Follow us on LinkedIn for more updates from the S2i2 team.
