Knowing What You Know – New OMB Regulations Require New Logging and Action
On May 22, 2026, the Office of Management and Budget issued Memorandum M-26-14, Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats. It took effect immediately, and it rescinded OMB Memorandum M-21-31, the 2021 logging memorandum issued after SolarWinds. The new policy applies to “agencies” as defined in 44 U.S.C. § 3502, but not to national security systems under 44 U.S.C. § 3552(b)(6), or to Department of Defense or Intelligence Community systems described in 44 U.S.C. § 3553(e). OMB Memorandum M-26-14, Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats 1–2 (May 22, 2026).
The memorandum’s stated premise is straightforward. Threat actors are using automation and artificial intelligence to move faster, gain unauthorized access, move laterally, and remain undetected. Agencies, therefore, need the ability to “rapidly detect, respond to, and analyze anomalous activity” through appropriate event logging. But M-26-14 is not simply a “collect more logs” memorandum. In fact, it expressly criticizes prior requirements that resulted in “retention of vast quantities of logging data without clear utility,” calling that approach neither operationally feasible nor cost-effective. The new mandate is therefore risk-based, not volume-based. OMB M-26-14, supra, at 1.
That is the cybersecurity point. The legal point is more dangerous. Logging creates knowledge. Knowledge creates duties. Duties create liability.
Once an agency, contractor, cloud provider, managed security provider, or regulated enterprise creates logs, collects telemetry, and generates alerts, it becomes much harder to say, “We did not know.” The organization may be deemed to know what its systems knew. It may be deemed to know what its logs showed. It may be deemed to know what a reasonable security program would have inferred from the available telemetry. Creating a log but failing to convert that log into actionable intelligence, and then failing to convert that intelligence into action, can create civil liability and, in extreme cases, potential criminal exposure. Knowing something and doing nothing is often worse than not knowing at all.
M-26-14 makes this problem explicit by defining logging around operational outcomes. Agencies must prioritize Continuous Event Monitoring, including logs, log management, and logging infrastructure that enable them to monitor activity in real time, flag anomalies, and respond promptly. They must also prioritize Threat Hunting, Investigation, Response, and Forensics, meaning logs and infrastructure that allow agencies to investigate and perform forensic analysis after a known or suspected compromise. OMB M-26-14, supra, at 2.
Those words matter. OMB is not asking agencies to possess logs. It is asking agencies to use logs. The memorandum requires these objectives across all agency-owned or agency-operated information systems, including systems operated by third parties on the agency’s behalf, and including IoT and operational technology where those devices are part of an agency information system. OMB M-26-14, supra, at 2.
This is where federal contractors should pay attention. Although the memorandum is formally directed to federal agencies, its operational reach extends to third-party systems operated on an agency’s behalf. That means contractors, cloud providers, SaaS providers, managed security providers, systems integrators, and operators of government-facing platforms should expect the requirements to flow through contracts, authorizations to operate, FedRAMP packages, incident response obligations, service-level agreements, and agency security reviews.
The specific requirements are substantial. CISA, working with OMB and the CISO Council, must publish a Logging Reference Architecture within 90 days of May 22, 2026. Agencies must then submit an Agency Logging Plan to OMB and CISA within 90 days after publication of that architecture. That plan must describe the operational steps required to deploy and maintain effective Continuous Event Monitoring and Threat Hunting, Investigation, Response, and Forensics capabilities. OMB M-26-14, supra, at 2–3.
The compliance deadlines then accelerate. Within 120 days after release of the Logging Reference Architecture, agencies must reach at least Basic, or Level 1, maturity across all elements of the maturity model. Within 180 days, they must reach Intermediate, or Level 2. Within 320 days, they must reach Advanced, or Level 3. When CISA updates the reference architecture, agencies must update their Agency Logging Plan within 30 calendar days, reach Intermediate within 60 calendar days, and reach Advanced within 120 calendar days. OMB M-26-14, supra, at 3–4.
The baseline technical requirements are equally important. Retained logs must be actively searchable for at least six months to support Continuous Event Monitoring and retrievable for one year to support threat hunting, investigation, response, and forensics. “Searchable” means the data can be immediately used for cyber defense without additional preparation. “Retrievable” means the data can be used after intermediary steps, such as thawing cold storage or replaying archived data into an analytics platform. OMB M-26-14, supra, app. B, at 1.
Agencies may use decentralized log storage, but logs must be readily available to the top-level agency Security Operations Center. Logs must include consistently accurate timestamps synchronized to a traceable time source, preferably using NTP or equivalent mechanisms and, where feasible, authoritative sources traceable to the U.S. Naval Observatory or NIST. Agencies are also directed to use resources such as Continuous Diagnostics and Mitigation, Hardware Asset Management, and Software Asset Management to determine whether logging coverage encompasses all information technology in agency systems, including IoT and OT. OMB M-26-14, supra, app. B, at 1.
Most significantly, the minimum logging baseline requires agencies to collect logs that can identify the identity used to perform operations, source and destination network addresses, protocols, ports, session attributes, accessed or modified objects and data, privilege-level changes, IT/OT/IoT infrastructure changes, suspicious activity detected by security tooling, known indicators of compromise, anomalous system or user activity, the quantity and types of data affected during an incident, attack vectors including initial access and lateral movement, and automated alerts for these categories. OMB M-26-14, supra, app. B, at 1–2.
That last requirement is the bridge between security compliance and liability. OMB is not simply requiring agencies to preserve evidence after the fact. It requires logs that generate alerts and support detection, hunting, investigation, and action. The maturity model confirms this. At higher maturity levels, logs must generate actionable alerts covering baseline requirements, and detections must be evaluated and tuned. At the optimal level, actionable alerts must cover at least 95 percent of baseline requirements and be routinely evaluated and tuned using advanced techniques such as machine learning or artificial intelligence. OMB M-26-14, supra, app. C, at 1.
This means that a failure to respond to logged evidence is no longer merely a security operations failure. It is potentially a governance failure, a compliance failure, a procurement failure, a records failure, and a litigation problem. If the logs showed repeated anomalous logins, unexplained privilege escalation, suspicious data movement, lateral movement, or access to sensitive data, the organization may be asked not only why the attack occurred, but why it ignored what its own systems were saying.
This is the “liability of knowing.” A company that does not log may be accused of negligence for inadequate visibility. A company that logs but does not analyze may be accused of negligence plus indifference. A company that analyzes but does not escalate may be accused of recklessness. A company that escalates but suppresses or fails to disclose may face exposure under securities law, false claims theories, privacy law, contractual cybersecurity clauses, obstruction principles, or, in the most extreme circumstances, criminal statutes.
M-26-14, therefore, should not be implemented as a storage project. It should be implemented as a knowledge-to-action governance project. Agencies and contractors should define what alerts mean, who owns them, when they must be escalated, what response timelines apply, how unresolved alerts are documented, when legal counsel is notified, when CISA or the FBI must be engaged, and when contractual, regulatory, or public disclosure obligations may be triggered.
The memorandum itself reinforces this externalization of knowledge. In the event of a known or suspected compromise of federal networks, agencies must provide logs and relevant data to CISA and the FBI upon request, to the extent consistent with applicable law, and should provide access within the requested timeframes to the greatest extent practicable. OMB M-26-14, supra, at 3.
That is another liability inflection point. Logs that once lived quietly in a SIEM may become evidence in a federal incident response, law enforcement investigation, inspector general review, congressional inquiry, civil discovery dispute, False Claims Act case, or regulatory enforcement action. Once created, logs do not merely help the defender. They help the investigator.
The practical advice is therefore blunt. Do not collect telemetry unless the organization has a plan to use it. Do not generate alerts unless the organization has a triage process. Do not buy visibility tools unless the organization has staffing, escalation paths, authority to act, and documented response procedures. Do not promise monitoring in a contract, security plan, FedRAMP package, ATO submission, or incident response plan unless the organization can prove that monitoring actually occurs. Do not represent “continuous monitoring” if the reality is unattended dashboards and unreviewed alerts.
For compliance, agencies and contractors should begin by mapping systems to the M-26-14 baseline. They should identify which logs establish user identity, network source and destination, data access and modification, privilege changes, infrastructure changes, suspicious activity, indicators of compromise, anomalous behavior, incident scope, attack vectors, lateral movement, and automated alerting. They should then determine whether those logs are searchable for six months, retrievable for one year, timestamped accurately, available to the top-level SOC, and tied to documented detection and response workflows.
For liability reduction, the more important step is to map each log source to a decision. What decision does this log support? Who makes that decision? How quickly? With what authority? What happens if the decision is not made? How is the failure documented? Who is accountable?
That is the real lesson of M-26-14. Logging is not a defensive talisman. It is not enough to know. In fact, knowing without acting may be worse than ignorance. Once the organization has created the machinery of knowledge, it has also created the evidence of its own inaction.
OMB has now made clear that federal logging policy is about effective and efficient visibility, not blind accumulation. But visibility is a two-edged sword. It can reveal attackers. It can also reveal negligence. It can support defense. It can also support liability.
The organization that succeeds under M-26-14 will not be the one that collects the most logs. It will be the one that can show a disciplined chain from event to alert, alert to intelligence, intelligence to decision, and decision to action.
