SIEM (security information and event management)

Every system you run produces logs: who signed in, from where, which files were opened, which firewall rules blocked traffic, which admin changed a setting. On their own, those logs are scattered across dozens of systems and often deleted after a few days. A SIEM gathers them centrally, stores them for as long as you choose, and runs rules and analytics across all of them to raise alerts. Microsoft Sentinel is Microsoft's cloud SIEM; Splunk and others are well-known alternatives.

A SIEM is powerful but not a set-and-forget tool. It needs someone to decide what to collect (which affects cost), tune the alert rules so staff aren't buried in noise, and investigate what it finds. That's why SIEMs usually sit inside a SOC or MDR service rather than being run by a small business directly.

Why it matters: audit logs are a HIPAA Security Rule technical safeguard, and frameworks like SOC 2 expect you to show you review security events. If something goes wrong, centralized logs are often the only way to answer “what did the attacker access?” — a question that drives breach notification decisions.

Example: a medical practice suspects a former employee logged in after leaving. Without centralized logs, Microsoft 365 might retain the evidence for only a limited period depending on license. With sign-in and audit logs kept longer in a SIEM or log archive, the practice can show exactly what was accessed, when, and from where.

For many small offices, the audit logs built into Microsoft 365, kept and reviewed properly, cover most needs before a full SIEM is justified.