---
{
  "title": "Security information and event management",
  "summary": "Centralize records and detection workflows without confusing collection with certainty.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    1
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Incident Response Recommendations, SP 800-61 Rev. 3",
      "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Centralize evidence and investigation work

Security information and event management, usually called SIEM, combines log collection, search, normalization, detection, and investigation workflows. Implementations vary, but the central purpose is to make relevant records usable across systems. A SIEM can help analysts connect identity, application, network, and endpoint activity that would otherwise remain in separate tools.

Centralization does not make every record accurate or complete. The platform can only analyze the events it receives, under the semantics and retention provided. Missing sources, parsing errors, delayed ingestion, and mistaken field mappings can all affect an investigation.

## Trace one alert to its evidence

A fictional team creates a detection for an unusual sign-in followed by a privileged role change. The SIEM receives identity events and administrative audit records. The rule joins them using the relevant identity and tenant identifiers within a defined time window.

An analyst opening the alert should be able to reach the original events, understand the matching logic, and see which sources contributed. A summary containing only “high risk” and an account name forces the analyst to rebuild the case before assessing it.

[[log-correlation]] explains why field meaning matters. If the administrative record's actor is confused with the target account, the rule may connect the wrong identities. Preserving raw events alongside normalized fields helps analysts inspect such problems.

## Operate the data pipeline

Monitor whether expected sources are reporting, whether important fields are populated, and whether delivery delay affects detection. A source may be present in the inventory but unusable for a particular rule because the required event category is disabled.

Retention should follow investigation and business requirements, with appropriate privacy and cost considerations. Longer storage can support historical questions, but retaining everything indefinitely creates its own handling burden. Decide which records are necessary and who can access them.

Protect the platform itself. Analysts may be able to search sensitive operational data, while administrative roles can change rules and retention. Use appropriate access separation and audit changes that affect monitoring.

## Judge the workflow by its outcomes

A SIEM's usefulness depends on whether signals lead to sound decisions. [[detection-engineering]] tests the rules and their assumptions; [[alert-triage]] checks the resulting cases. Dashboards that show impressive volumes do not establish that important behaviors are covered.

For practice, follow a harmless authorized role change from its source system into the SIEM. Compare raw and normalized fields, note delivery delay, and confirm the rule's interpretation. Then draft the evidence an analyst needs to investigate a similar unauthorized change. Include one known blind spot and the action required if the relevant source stops reporting.

## Related concepts

- [[logs-and-telemetry]]