What log infrastructure actually means in a state context
Security event logging is the practice of recording what systems, users, and applications do — authentication attempts, file access, network connections, configuration changes, privilege escalations — and retaining those records long enough to support investigation, threat hunting, and compliance. Log infrastructure is the collection of systems, pipelines, storage, and analysis tools that make those records accessible and useful.
In the federal government, OMB Memorandum M-21-31 (2021) was issued "to raise logging baselines and enhance agencies' knowledge of events occurring in their systems." On May 22, 2026, OMB rescinded it with Memorandum M-26-14. OMB found that some M-21-31 requirements, such as "the retention of vast quantities of logging data without clear utility," were "neither operationally feasible nor cost-effective for most agencies." M-26-14 replaces them with a risk-based approach built on two priorities: continuous event monitoring (CEM) and threat hunting, investigation, response, and forensics (THIRF). CISA published a supporting Logging Reference Architecture on August 20, 2026. Both are federal civilian guidance and do not bind state government, but both are detailed operational references, and OMB's own correction is a useful warning to states against retaining everything without a defined use.
The NIST SP 800-92 "Guide to Computer Security Log Management" (September 2006) describes the foundational problem: logs are generated by nearly every IT component, but they are inconsistently configured, stored in different formats, retained for different durations, and rarely analyzed in aggregate. In state government, that fragmentation can be compounded by the agency-by-agency structure. In a hypothetical state with 40 agencies managing their own systems, that can mean 40 logging configurations, 40 sets of retention decisions and no central view of any of them.
The three capabilities that require log infrastructure first
Zero trust. The CISA Zero Trust Maturity Model v2.0 (April 2023) organizes zero trust across five pillars — Identity, Devices, Networks, Applications and Workloads, and Data — and describes progression from Traditional to Optimal maturity in each. CISA's model treats visibility as a cross-cutting capability: at Advanced maturity an agency "expands the automated collection of logs and events enterprise-wide … for centralized analysis," and at Optimal it maintains "comprehensive visibility enterprise-wide via centralized dynamic monitoring and advanced analysis of logs and events." That monitoring is, mechanically, a log analysis problem. A state can implement multi-factor authentication, micro-segmentation, and conditional access policies. Without centralized logging and analysis, it cannot detect when those controls are being circumvented, when a credential is being misused, or when lateral movement is occurring. The access control layer of zero trust generates the logs; the analysis layer makes them actionable. A transition plan that addresses controls but not log infrastructure has committed to the control layer without the analysis layer.
NIST SP 800-207 "Zero Trust Architecture" (August 2020) makes this dependency explicit: the Policy Decision Point at the center of a zero trust architecture relies on continuous signals from monitoring systems. Without those signals, access decisions revert to static policy — which is not zero trust, it is conventional access control with a different label.
AI-assisted threat detection. User and Entity Behavior Analytics (UEBA), anomaly detection, and AI-powered threat correlation all require the same input: a consistent, well-labeled stream of security events collected over time. A threat detection model trained on incomplete or inconsistently formatted log data will produce unreliable alerts. More fundamentally, threat detection models require a baseline — what normal authentication behavior, file access patterns, and network activity look like — that can only be established from historical logs. A state agency that begins collecting logs in earnest after a security incident is building a baseline on post-incident data, which is not the same thing. The value of AI-assisted detection scales with the quality, coverage, and history of the underlying log infrastructure.
Incident response. Understanding an intrusion — how the initial access occurred, which systems were touched, what data moved, how far lateral movement progressed — requires logs that predate the incident. NIST SP 800-92 notes that many logs have a maximum size and, once it is reached, may overwrite old data or stop logging altogether, which can erase evidence long before an investigator needs it. The joint #StopRansomware Guide recommends centralized log management with a SIEM, keeping logs for critical systems "for a minimum of one year, if possible," and keeping PowerShell logs for "at least 180 days." NIST SP 800-92 treats retention as a policy decision each organization must define for every log type, because that decision determines what evidence will exist when it is needed.
What a credible log architecture requires
A state security log program needs to answer four structural questions before it can support the capabilities above:
Coverage. Which systems generate logs that matter, and are those logs being collected? Cloud services, on-premises servers, endpoint software, network devices, authentication systems, and applications each generate relevant logs, and coverage across them can be uneven. Authentication systems may be logged while endpoint behavior is not, and cloud workloads may log to platform-native tools that are not integrated with anything else.
Collection and normalization. Logs from different systems arrive in different formats. A SIEM or log aggregation platform converts them into a consistent schema that supports correlation and search. Without that normalization, an analyst investigating an incident cannot efficiently search across authentication logs, network flows, and endpoint events simultaneously.
Retention. Different log types require different retention periods depending on their investigative value and applicable regulations. NIST SP 800-92 points to applicable laws, regulations and organizational policies, a balance between risk reduction and the time and resources required, and available log storage space as the relevant factors. As a federal reference point, OMB M-26-14 (May 2026) sets a minimum baseline: logs must be actively searchable for at least 6 months and retrievable for a year after creation, and agencies must still comply with any longer records-schedule obligations. State requirements will vary but should come from explicit retention decisions rather than defaults.
Access and analysis. Log data has limited value if it is retained but not accessible for timely analysis. A SIEM with tuned detection rules, or a managed security service with analyst access to state log data, provides the operational layer. States that retain logs but lack search and correlation capability have the evidence but cannot use it.
CISA resources and the SLCGP funding path
The State and Local Cybersecurity Grant Program (SLCGP) was authorized under Section 70612 of the Infrastructure Investment and Jobs Act (Public Law 117-58, November 15, 2021) for fiscal years 2022 through 2025 and is run by DHS through CISA (program and cybersecurity lead) and FEMA (grant administration). As enacted, the program's requirements were set to terminate on September 30, 2025. The most recent funding round the FEMA program page lists is FY2025 ($91.75 million), though CISA's page shows Cybersecurity Plan resubmissions due January 30, 2026. States should confirm the program's current authorization status before building log infrastructure plans around new SLCGP awards.
SLCGP applicants must submit a Cybersecurity Plan developed through a state Cybersecurity Planning Committee. The statute asks applicants to describe how they will "monitor, audit, and, track network traffic and activity" [sic], and CISA's required best practices include "Enable enhanced logging." Log infrastructure is not a side investment under SLCGP. It is one of the program's own stated priorities.
CISA also offers several no-cost services relevant to log infrastructure, catalogued at cisa.gov/resources-tools/services, including network monitoring, vulnerability scanning, and cybersecurity assessments that can establish a baseline for identifying log coverage gaps. The MS-ISAC, operated by the Center for Internet Security (CIS) and member-funded since 2025, offers security monitoring services to state and local governments. States that are not ready to run their own SIEM infrastructure can use it as one managed log-analysis option, but should confirm current membership costs and service scope.
Architecture choices and their operational tradeoffs
State CISOs facing the log infrastructure question have three practical architecture options:
Centralized state SIEM. The state operates a SIEM platform that ingests logs from all agencies. This provides maximum visibility and control, enables cross-agency correlation (detecting lateral movement that crosses agency boundaries), and supports state-level threat hunting. The cost and staffing requirements are significant: a SIEM without adequate staffing to tune and analyze it generates alert noise that erodes its value. States that have consolidated other IT infrastructure (shared data centers, centralized identity systems) are better positioned to extend that model to logging.
Managed security service. The state contracts with MS-ISAC or a commercial managed security service provider (MSSP) to collect and analyze logs. This reduces internal staffing requirements and leverages established detection content, but requires the state to ensure that its data governance requirements, incident notification obligations, and contractual access rights are addressed in the service agreement. Not all managed services provide the same visibility or retention; the state should specify coverage, retention periods, alert criteria, and data portability before contracting.
Hybrid. Core systems — authentication, privileged access, network perimeter, high-sensitivity applications — are logged to a state-operated or state-managed SIEM. Smaller agencies and lower-priority systems use managed services or existing tools with defined minimum standards. This approach manages cost while ensuring centralized visibility for the highest-priority targets.
The choice depends on the state's existing IT consolidation posture, available budget and staffing, and the timeline of other security investments. A state that is implementing zero trust controls across its major agencies in the next 18 months needs log infrastructure that can support continuous monitoring of those controls before the controls go live — not on the same schedule, but ahead of it.
The sequencing decision
Zero trust procurement and log infrastructure decisions can end up on parallel tracks. Procurement for identity tools, micro-segmentation, and conditional access platforms is proceeding while log infrastructure sits in a later budget cycle. The operational consequence is that the controls go in but the analysis layer is not ready to confirm they are working. Detection of a sophisticated intrusion that circumvents a newly deployed control relies on the log infrastructure being able to see the circumvention.
The sequencing argument is not that log infrastructure must be complete before any zero trust investment begins. It is that states should map which zero trust controls they are deploying, what log sources those controls depend on for continuous monitoring, and whether that log infrastructure will be in place when the controls become operational. Gaps in that alignment are not budget-cycle slippage — they are security architecture gaps that leave deployed controls unmonitored.
State CISOs who have presented zero trust transition plans to executive leadership, or who have built zero trust projects into SLCGP Cybersecurity Plans, should be explicit with those stakeholders about the log infrastructure dependency. A transition plan that shows zero trust control milestones without corresponding log infrastructure milestones is describing half an architecture.
Sources and further reading
- NIST SP 800-92: Guide to Computer Security Log Management (September 2006)
- NIST SP 800-207: Zero Trust Architecture (August 2020)
- CISA Zero Trust Maturity Model v2.0 (April 2023)
- OMB M-26-14: Ensuring Effective and Efficient Agency Logging and Network Visibility (May 22, 2026)
- CISA Logging Reference Architecture (August 20, 2026)
- CISA #StopRansomware Guide
- CISA State and Local Cybersecurity Grant Program
- FEMA State and Local Cybersecurity Grant Program
- MS-ISAC (Center for Internet Security)
- Infrastructure Investment and Jobs Act, Section 70612 (Public Law 117-58, November 2021)
Spartan X's cybersecurity architecture advisory work for state government focuses on this kind of sequencing: designing a log architecture proportionate to a state's risk profile and operating structure, and timing that investment against zero trust, AI-enabled monitoring and SOC development. That planning benefits more from practitioners who have worked through the tradeoffs than from any single vendor's platform roadmap.
