L1: Sources are connected ad hoc, often with default connector settings and no record of who requested them or why.

L2: New sources go through a basic request process; documentation exists for major sources only.

L3: A standard onboarding process defines ownership, format, parsing, and validation before a source goes live.

L4: Onboarding requires documented justification tied to security value, business risk, or investigative need.

L5: Onboarding is templated and automated, with periodic review of existing sources against the same criteria.

L1: No mapping exists between data sources and detection, investigation, or compliance use cases.

L2: Mapping exists for a handful of high-profile sources and is maintained informally.

L3: All major sources are mapped to documented use cases; unmapped data is identifiable.

L4: Mapping is reviewed on a cadence; sources with no active use case are flagged for filtering, tiering, or removal.

L5: Use-case mapping drives onboarding, retention, and cost decisions as a standing part of governance.

L1: Data lands in source-native formats; field naming is inconsistent across sources.

L2: Normalization is applied opportunistically for a few sources.

L3: A documented normalization standard (e.g. ASIM, ECS, CIM) is applied where appropriate; deviations are documented.

L4: Normalization coverage is measured; detections are written against normalized schemas by default.

L5: Normalization is enforced in the ingestion pipeline with automated conformance testing.

L1: All events are ingested as delivered; no filtering is applied.

L2: Some verbose sources are filtered reactively after cost or noise complaints.

L3: Filtering standards exist for known low-value events and are applied at onboarding.

L4: Reduction opportunities are reviewed on a cadence using volume and cost data; filters are tested so no detection depends on dropped events.

L5: Filtering is managed as code with automated regression checks against detection and investigation requirements.

L1: A single retention setting is applied globally, typically the platform default.

L2: Retention is adjusted for a few tables due to cost or compliance pressure; no overall strategy exists.

L3: Retention tiers are differentiated by use case (hot, warm, archive) and documented.

L4: Tier placement is reviewed against actual query and investigation patterns; restore procedures are tested.

L5: Retention and tiering are automated by policy and optimized continuously using usage analytics.

L1: SIEM cost is known only at the invoice level.

L2: Cost is reviewed periodically at workspace level; spikes are investigated after the fact.

L3: Cost is visible at source or table level and reviewed monthly with anomaly follow-up.

L4: Cost is tied to use cases; onboarding and retention decisions include cost-to-value analysis, with budget alerting in place.

L5: Cost management is proactive: forecasting, per-outcome costing where feasible, and leadership reporting.

L1: No health monitoring exists; source outages are discovered during investigations.

L2: Ad hoc volume checks are performed on major sources; no criticality tiers exist.

L3: Automated heartbeat and absence alerting covers critical sources, with documented criticality tiers.

L4: Completeness validation covers volume baselining and schema-drift detection, with health SLOs per tier.

L5: Pipeline failures trigger automated remediation or failover; telemetry health is reported as a leadership metric.

L1: No named owners exist; it is unclear who may change a detection.

L2: Ownership is informally understood for some high-priority rules.

L3: Priority detections have named owners recorded in detection metadata.

L4: All production detections have owners; ownership is reviewed on a cadence and on personnel change.

L5: Ownership is enforced by tooling — unowned detections are blocked from deployment or flagged automatically.

L1: Tuning is reactive, after analyst complaints; suppressions are undocumented.

L2: Tuning occurs regularly, but changes are tracked informally.

L3: Tuning follows a documented process with recorded rationale; noisy detections are identified from metrics.

L4: Tuning is driven by false-positive and alert-quality metrics on a defined cadence; suppression rules are time-bound and reviewed.

L5: Tuning proposals are generated from telemetry (auto-identified noise clusters) and applied under change control.

L1: Detections are edited directly in the console; no version history exists.

L2: Some content is exported or backed up; no review flow exists.

L3: Detection content is version-controlled with peer review for changes.

L4: A CI/CD pipeline deploys detections; console drift is detected and reconciled.

L5: The full lifecycle is managed as code, including metadata, tests, and rollout and rollback automation.

L1: Detections are released without testing.

L2: Manual spot-checking against historical data is performed for some rules.

L3: Standard pre-release validation covers syntax checks and sample telemetry or replay for priority detections.

L4: An automated test harness runs in the pipeline; periodic adversary emulation or replay validates production coverage.

L5: Validation is continuous — scheduled emulation and detection health checks feed the backlog automatically.

L1: Incident and hunt findings are not fed back into detection content.

L2: Feedback happens informally when analysts raise issues.

L3: Post-incident and hunt reviews include a detection-gap step that produces backlog items.

L4: Gap-to-detection turnaround is measured; hunting outputs regularly convert to production detections.

L5: The feedback loop is institutionalized and measured end-to-end, driving coverage strategy.

L1: No coverage view exists; it is unknown which threats detections address.

L2: ATT&CK tags exist on some detections; no aggregated view is maintained.

L3: A coverage map is maintained against a documented organizational threat profile.

L4: Coverage gaps are prioritized in the backlog by threat relevance; coverage is reported on a cadence.

L5: Coverage is validated by emulation — not tags alone — and drives investment decisions.

L1: No structured threat intelligence input reaches detection work.

L2: IOC ingestion is ad hoc, with no lifecycle management.

L3: Threat intelligence feeds are curated and mapped to detections; IOC aging and expiry are managed.

L4: Threat intelligence drives proactive detection development for relevant TTPs; time from intel to detection is measured.

L5: Threat intelligence is integrated across enrichment, hunting, and the detection lifecycle with relevance scoring.

L1: Analysts gather context manually for every alert.

L2: Basic enrichment (geo-IP, reputation, whois) is automated for some alert types.

L3: A standard enrichment set is applied automatically to priority incident types before analyst pickup.

L4: Enrichment coverage is measured and includes internal context: asset criticality, identity, and ownership.

L5: Enrichment is extended continuously based on analyst time studies, with quality monitored.

L1: Ticket creation and case updates are handled manually outside the SIEM workflow.

L2: Automated case creation exists; assignment and routing are manual.

L3: Incidents are routed by type and severity to the right queue, with bidirectional status sync.

L4: Routing rules are maintained under change control; misrouting is measured and tuned.

L5: Routing adapts based on outcomes; the full case lifecycle is integrated across tools.

L1: Response steps are undocumented and depend on individual analysts.

L2: Playbooks exist for a few incident types but are inconsistently used.

L3: Documented playbooks cover high-volume incident types and are consistently followed.

L4: Playbooks are versioned, tested, and updated from lessons learned; usage is measured.

L5: Playbooks are continuously improved with automation-first design; deviations are reviewed.

L1: Containment is fully manual or performed without defined approval.

L2: Containment actions are defined for common scenarios; approval is verbal or informal.

L3: A documented approval matrix exists; automated containment is gated by explicit approval steps.

L4: Approval workflows are built into tooling with SLAs and a full decision audit trail.

L5: Pre-approved containment covers defined high-confidence scenarios with automatic rollback criteria.

L1: Automation failures are discovered by chance; no rollback path exists.

L2: Failures surface as errors; recovery is manual and undocumented.

L3: Playbooks define failure handling and manual rollback steps.

L4: Automated actions have tested rollback procedures; failures alert and route for review.

L5: Rollback is automated where feasible; failure modes are tested proactively.

L1: No reliable record exists of what automation did.

L2: Action logs exist but are scattered or incomplete.

L3: All automated actions are logged centrally with actor, trigger, and outcome.

L4: The audit trail is queryable and reviewed; it supports incident reconstruction and compliance.

L5: Audit data is monitored for anomalies in automation behavior itself.

L1: SIEM responsibilities are informal or fragmented across teams.

L2: Dedicated operators exist; boundaries between platform, detection, and response duties are blurry.

L3: Roles are defined and documented across platform operations, detection engineering, response, and hunting.

L4: Role coverage is reviewed against demand; skill development paths are defined per role.

L5: Roles evolve deliberately with capability strategy; succession and cross-training are managed.

L1: No single owner exists for the SIEM capability.

L2: Ownership is nominal, without a clear mandate or budget authority.

L3: An accountable owner exists with a defined mandate, budget, and decision rights.

L4: Ownership includes service definitions and commitments to stakeholders.

L5: Ownership operates as product management — roadmap, stakeholder council, and value reporting.

L1: No backlog exists; work is driven by interrupts.

L2: Informal to-do lists are kept per team member.

L3: A shared, prioritized backlog exists with a regular review cadence.

L4: Backlog throughput and age are measured; capacity is allocated between run and improve work.

L5: Improvement investment is steered by measured outcomes; the cadence is institutionalized.

L1: No KPIs are defined beyond raw alert counts.

L2: A few operational metrics are tracked inconsistently.

L3: A documented KPI set covers quality, timeliness, and coverage, with dashboards in place.

L4: KPIs are reviewed with leadership; thresholds trigger action.

L5: KPIs evolve with the threat and business context; leading indicators are used, not just lagging ones.

L1: SIEM priorities are disconnected from business risk.

L2: High-level awareness of critical assets exists but is not reflected in configuration.

L3: Detection and data priorities are mapped to documented business risks and crown-jewel assets.

L4: Risk alignment is reviewed with risk owners on a cadence and drives investment.

L5: SIEM capability planning is integrated into enterprise risk management.

L1: No post-incident review practice exists.

L2: Reviews happen for major incidents only; actions are rarely tracked.

L3: A defined review process exists with tracked actions across incidents and engagements.

L4: Action completion is measured; recurring findings are analyzed for systemic fixes.

L5: Improvement is institutionalized — reviews feed the backlog, KPIs, and training.