CISA’s new logging guidance turns a technical cost decision into a board question about what a company can prove under regulatory pressure.
What changed
On 20 August 2026, the US Cybersecurity and Infrastructure Security Agency published its Logging Reference Architecture, guidance for Federal Civilian Executive Branch agencies on logging, visibility and operational standards.
It matters beyond the federal audience because it changes the framing. Logging is often treated as a technical collection problem: more sources, more telemetry, more storage, more dashboards. CISA frames it as an evidence problem. Every logging decision should trace back to a specific question the organisation would need answered during a breach.
That is a board-level idea in technical clothing.
The Logging Reference Architecture converts existing US Office of Management and Budget logging policy direction into concrete architectural, operational and governance choices. It is built around two goals: continuous event monitoring, which supports real-time detection, and post-incident reconstruction and forensics, which supports the harder later work of proving what happened, when, what was touched, what was lost, and what remains uncertain.
CISA also addresses cost directly. It does not argue for expensive full centralisation of every log forever. It favours disciplined tiering: what must be immediately searchable for monitoring, what can move to cheaper but retrievable storage, and what needs immutable, evidentiary handling. The federal reference baseline it cites is six months of active search access and one year of retention. Its warning on centralisation is concise: consistency and visibility improve only if the data stays timely, trustworthy and usable.
Why it matters
The non-obvious governance issue is that a company’s incident evidence ceiling is usually set before the incident begins.
It is set by decisions about logging coverage, retention, searchability, system clocks, identity records, endpoint telemetry, cloud audit trails, network flow data, third-party access records and backup integrity. Many of those decisions are made below board level. They appear at the time as IT cost-management choices, platform configuration, or storage tradeoffs. During an incident they become legal, regulatory, insurance and board evidence.
If records were never collected, management cannot reconstruct them later. If they were retained too briefly, a slow intrusion disappears from view. If logs sit in cheap storage but cannot be retrieved quickly, they may miss the clock set by a regulator or a disclosure duty. If a SIEM is treated as the sole system of record, gaps in ingestion, normalisation or integrity become gaps in the company’s account of events.
Several regimes now compress the time available to form that account. The EU Digital Operational Resilience Act has applied to EU financial entities since 17 January 2025 and requires major ICT-related incidents to be classified and reported within short regulator-set limits, against criteria such as clients affected, duration, data losses, service criticality and economic impact. The NIS2 Directive adds incident-notification duties across many sectors, with an early-warning step within 24 hours. The US Securities and Exchange Commission requires public companies to disclose material cybersecurity incidents on Form 8-K, generally within four business days of a materiality determination. The GDPR requires breach notification without undue delay and, where feasible, within 72 hours.
Those regimes differ. The board issue is common: a company must make defensible statements before the facts are comfortable.
What changes for management
Management should treat logging architecture as part of incident readiness, not a subsection of security tooling.
The CISA guidance offers a useful test. For each serious incident scenario, management should be able to state the questions that would need answers, then show which records would answer them. That reverses the usual conversation. The starting point is not whether a tool collects enough data. It is whether the company can answer the questions it will be asked, in the time it will have.
For a ransomware scenario, those questions include when initial access occurred, which identity was used, which systems were encrypted, whether data was moved, and which backups stayed clean. For a cloud compromise, they include which credentials were abused, which administrative actions occurred, which data stores were reached, and whether logs were altered. For a supplier access incident, they include when the supplier connected, what was reachable, and whether the access path is now closed.
The task is to map those questions to logging controls across the full chain: collection, transport, normalisation, storage, retention, access, protection and validation. CISA’s checklists are useful because they cover that whole chain rather than collection alone.
AI needs its own discipline. CISA treats AI-generated outputs as derived data, not authoritative records, and says material decisions require human review, with the link between original records and AI outputs preserved. A generated summary can speed triage, but it cannot serve as the evidence unless the underlying records remain available and intact.
What changes for the board
The board does not need to design the logging architecture. It does need to govern the risk that technical logging choices silently cap what the company can later prove.
That shifts the oversight question from whether the company has a SIEM to what the company can reconstruct. It also reframes the budget line: logging spend buys future evidentiary capacity, not only monitoring.
A board should expect management to explain the position in plain language: which incident scenarios would create the most disclosure, regulatory, customer or operational pressure; which facts would need to be established quickly; which logs provide those facts; how long those logs stay searchable; which records are immutable; and which critical systems or third parties sit outside reliable coverage.
The board should also expect tension. Full collection and long retention cost money. Over-collection raises privacy and data-minimisation questions. Centralisation improves visibility but concentrates dependency on one platform. Cheap storage lowers cost but slows retrieval. These are governance tradeoffs that belong in the risk appetite discussion, not only in a technical backlog.
This is also where outside perspective helps when it is tied to management’s actual environment. Turning a federal reference architecture into board-usable scenarios takes judgement about likely incidents, regulatory exposure, business services and third-party dependencies, and about what evidence directors would need under pressure.
Questions boards should now ask
- Which cyber incident scenarios would force the fastest regulatory, market, customer or insurance reporting by the company?
- For each, what facts would management need to establish within the first 24 and 72 hours?
- Which log sources prove those facts, and which critical facts would rest on inference rather than records?
- How long are the relevant logs actively searchable, and how long are they retained in retrievable form?
- Which records are protected from alteration or deletion after an attacker gains elevated access?
- Which cloud, identity, endpoint, network, backup and third-party access logs sit outside current coverage?
- Can management retrieve archived logs fast enough to support incident classification, materiality assessment and regulatory notification?
- How are AI-generated security summaries tied back to original records, and who reviews them before material decisions?
- When did the company last run an incident exercise that tested evidence reconstruction, not only technical containment?
Practical implications
The CISA Logging Reference Architecture is a prompt for a board-visible review of evidence readiness.
It should start with a small set of high-consequence scenarios, identify the questions regulators, courts, insurers and directors would ask, and test whether current logging choices can answer them.
The output should be simple enough for board use: a map of evidence gaps by scenario, a retention and searchability profile for critical log sources, the systems where logging is partial or dependent on third parties, and a costed set of options for closing the gaps that matter.
The board should resist false comfort from tool names. A mature logging position is not demonstrated by owning a SIEM, adopting AI triage, or centralising large volumes of telemetry. It is demonstrated by the ability to reconstruct events from records that are timely, trustworthy and usable.
The deadline in the guidance is federal: agencies must update their enterprise logging strategy and submit an Agency Logging Plan to OMB and CISA by 18 November 2026. Private companies carry no such obligation, but CISA explicitly encourages critical infrastructure operators and other private organisations to use the Logging Reference Architecture and its assessment checklists as a benchmark.
That makes it useful to boards now. It gives directors a sharper way to ask whether the company’s incident reporting capability is supported by evidence or limited by past storage decisions.
The point is uncomfortable but practical. A company cannot disclose, defend or explain facts it did not preserve. Logging architecture decides, in advance, how much of the truth will be available once the clock starts.