Microsoft Sentinel works best when data collection and detection engineering are designed as one system. A security team can ingest enormous amounts of telemetry and still miss important attacks if the data is incomplete, badly normalized, too expensive to retain, or disconnected from clear detection hypotheses. The architectural question is therefore not “Which logs can we send to Sentinel?” but “Which security decisions must the SOC make, and what evidence must exist for those decisions to be reliable?”
That distinction fits the current SC-100 perspective. Cybersecurity architects are expected to connect security operations, identity, data, applications, infrastructure, and governance rather than treat the SIEM as an isolated logging service. The operational counterpart is SC-200, where analysts configure Microsoft Sentinel, create KQL queries, investigate incidents, engineer detections, and automate response. A sound Sentinel strategy gives those analysts useful evidence without turning telemetry volume into the primary measure of maturity.
Start with detection questions before choosing data sources
Begin with the attack paths, policy failures, and operational questions the organization must be able to detect. For an identity compromise, the SOC may need sign-in events, role changes, authentication details, device context, directory audit events, and endpoint activity. For cloud-resource abuse, network flows may be less valuable than control-plane changes, workload identities, secret access, and the resulting resource activity. Writing those questions first prevents a common architecture failure in which a connector is enabled simply because it exists.
Use threat scenarios to distinguish evidence that is mandatory from telemetry that is merely interesting. The goal is not to predict every adversary action. It is to identify the observables needed to confirm or reject important hypotheses: who acted, from where, against which asset, with what privilege, and what changed afterward. A broad threat-landscape view can help generate scenarios, but the final data plan should be grounded in the organization’s actual identities, applications, networks, cloud services, and business-critical assets.
Make the questions testable. For each scenario, write the minimum evidence that would let an analyst decide whether the behavior is expected, suspicious, or confirmed malicious. If the answer depends on a field that the source does not provide, record that as a coverage gap before building the rule. This prevents a detection backlog from filling with ideas that cannot be validated against available telemetry.
Review the questions with analysts who actually investigate incidents. Architecture teams can overestimate the value of a source because the schema looks rich on paper, while responders know that a different field or system is what resolves uncertainty. That review also exposes operational gaps such as data that arrives too slowly for real-time response but remains valuable for retrospective hunting.
Classify sources by security value, not by collection convenience
Create source tiers that reflect how quickly data is needed and what decisions depend on it. Tier-one sources usually support high-severity detection and incident response: identity, endpoint, email and collaboration, cloud control-plane, privileged activity, and the logs of critical applications. A second tier may support hunting, audit, and broader context. A third tier can contain high-volume data retained primarily for long-term investigation or compliance. The tiers should determine onboarding priority, service expectations, and retention rather than being labels added after ingestion.
For each source, document ownership, expected event volume, schema, latency, retention need, failure mode, and the detections that depend on it. This makes telemetry a managed security dependency. If a connector silently stops, the team should know which analytics rules are now blind. If a source changes fields, there should be a way to identify affected queries. The SIEM model becomes useful only when collection, correlation, and response are tied to explicit security outcomes.
Source tiers also help during budget discussions. Instead of arguing that a log is “important,” the security team can show which detections, investigations, or compliance obligations depend on it and what happens if retention is reduced. That makes cost optimization a risk decision rather than a generic request to cut ingestion. It also creates a principled way to move verbose secondary data into lower-cost storage without weakening high-priority detections.
Design connectors and ingestion controls as production interfaces
Data connectors should be treated like production integrations. Test authentication, permissions, event completeness, duplicate behavior, time stamps, regional considerations, and failure alerts. Where supported, data collection rules and transformations can reduce unnecessary ingestion or shape records before they reach their final tables. Filtering should be deliberate: removing a high-volume field can save money, but removing the field that distinguishes a service account from a human user can make a future investigation impossible.
Changes to ingestion deserve version control and change review because they can alter detection behavior without changing a single analytics rule. Keep a small validation query for each critical source that proves recent data is arriving with expected fields. Monitor ingestion gaps and unusual volume changes. A sudden drop might mean a broken collector, while an unexpected spike could indicate either a configuration problem or a real security event. Data health belongs on the same operational dashboard as detection health.
Design a rollback path for ingestion changes. A new transformation can unexpectedly drop records, rename fields, or change data types that existing rules depend on. Test changes in a controlled workspace or against representative samples, compare record counts and schema, and keep the previous configuration available until dependent detections are verified. Data pipelines deserve the same deployment discipline as application code because a pipeline failure can remove visibility across many rules at once.
Normalize where cross-source reasoning provides real value
Microsoft Sentinel’s Advanced Security Information Model provides normalized schemas and parsers so detections and hunts can work across heterogeneous sources. Normalization is especially valuable for common event families such as authentication, DNS, network sessions, process activity, audit events, and newer agent telemetry. Instead of every analyst learning every vendor’s field names, normalized content can ask a security question in consistent terms and expand automatically as additional compatible sources are onboarded.
Do not normalize merely for architectural neatness. Keep source-native fields when they contain product-specific evidence that analysts need, and use ASIM where source-agnostic logic improves reuse. Query-time parsers provide flexibility, while ingest-time normalization can improve performance for supported schemas. The decision should consider query cost, detection reuse, parser maintenance, and forensic fidelity. A normalized layer is most valuable when it simplifies real analytics without hiding the details required for deep investigation.
Normalization should also be governed like code. Document which parser version a rule expects, test custom parsers against representative events, and avoid changing normalized semantics merely to make one query easier. If the same source appears through two ingestion paths, verify that normalization does not create duplicate events. Analysts should be able to move from normalized fields back to source-native evidence when an investigation requires exact vendor detail.
Choose retention tiers according to investigative value
Retention design should distinguish hot analytical needs from long-horizon investigation. Microsoft Sentinel’s analytics tier is intended for security data that must be queried interactively and frequently, while the data lake tier supports cost-conscious retention of secondary data over longer periods. That makes it possible to keep the most operationally valuable evidence fast while preserving lower-frequency context for historical hunts and investigations.
The correct retention period depends on detection latency, dwell-time assumptions, regulatory requirements, and the time needed to reconstruct incidents. A source used in a rule that looks back 24 hours requires different performance from data kept for a six-month retrospective hunt. Review retention when detections, threat models, or regulations change. Storage architecture should not force the SOC to delete useful evidence simply because all logs were placed in the same expensive tier.
Retention architecture should include recovery and legal hold scenarios. Security teams sometimes discover months later that a campaign began before the first alert. Long-horizon data can support that reconstruction, but only if timestamps, identifiers, and source fidelity remain usable. Test historical queries occasionally rather than assuming archived data will be easy to retrieve during a crisis. A retention policy is operational only when the team knows how to use the retained evidence.
Build a detection portfolio rather than a pile of rules
Detection strategy should include multiple kinds of logic. Scheduled analytics rules can look for patterns in raw data over defined intervals. Product-native detections contribute high-fidelity signals. Correlation can join evidence across domains. Behavioral and anomaly methods can reveal activity that does not fit a simple signature. Hunting queries provide exploratory coverage and can later become detections when a hypothesis proves valuable. The portfolio should be mapped to threats and business assets, not organized only by who wrote each query.
For network-heavy environments, basic distinctions such as detection versus prevention still matter. Sentinel is often the place where signals are correlated and investigated, but prevention can occur in endpoints, identities, firewalls, cloud controls, or email systems. Architects should avoid designing the SIEM as the only defensive layer. Strong detections work best when they connect to controls that can contain or block the behavior being observed.
Map detections to business-relevant assets as well as tactics or techniques. A credential-theft rule on a developer workstation and the same rule on a domain administrator’s device should not necessarily produce identical triage. Severity logic can incorporate asset value, account privilege, or data sensitivity when those attributes are trustworthy. Context-aware prioritization reduces the temptation to solve alert overload by simply suppressing noisy rules.
Preserve entities and context so incidents tell a coherent story
Detection output should identify meaningful entities such as users, hosts, IP addresses, cloud resources, applications, and mailboxes. Good entity mapping allows analysts to pivot from an alert to related activity without rewriting the investigation from scratch. Context can include asset criticality, identity privilege, data sensitivity, device risk, internet exposure, and threat intelligence. The same alert may deserve very different priority when it affects a privileged identity or a production database.
Identity context is particularly important because many cloud attacks cross from authentication to resource access. The administration and governance concepts behind SC-300 help explain why sign-in events, role assignments, Conditional Access results, service principals, and workload identities should be part of the detection architecture. The SOC needs enough context to distinguish a failed user login from a compromised privileged workload using a valid token.
Use enrichment cautiously because stale context can be worse than missing context. Asset ownership, privilege, and sensitivity data should have known sources and refresh intervals. If a criticality tag is six months out of date, it may mislead triage. Treat enrichment datasets as production dependencies with owners and quality checks, just like event sources. The incident record should help an analyst understand why an alert was prioritized, not hide the inputs behind an opaque score.
Run detection engineering as a measurable lifecycle
Every important rule should have an owner, purpose, data dependencies, expected entities, severity logic, tuning history, validation method, and review date. Test rules with known benign and suspicious examples where practical. Measure more than alert count. Useful metrics include time to triage, true-positive rate, missed-event findings, repeated false-positive causes, percentage of high-risk techniques with validated coverage, and the number of rules degraded by broken data sources.
Create feedback loops from incidents and hunts into the detection backlog. If an analyst repeatedly writes the same pivot query during investigations, that may justify enrichment or a new rule. If an alert is always closed for the same benign reason, tune the logic or add context rather than training analysts to ignore it. Detection engineering should reduce uncertainty for responders; it should not maximize the number of alerts that can be generated.
Detection reviews should include red-team, purple-team, and incident-derived evidence when available. A rule that has never fired is not necessarily useless, but it should have some validation showing that its data dependencies and query logic work. Simulated activity can expose missing fields, broken entity mapping, or unrealistic thresholds before an attacker does. The goal is confidence in coverage, not artificial test alerts created only to satisfy a dashboard.
Architect for the unified Defender portal and an operating model that can change
Microsoft is moving Sentinel operations into the Microsoft Defender portal, with Azure-portal support scheduled to end after March 31, 2027. That transition reinforces a broader architectural trend: security operations increasingly combine Sentinel data with Defender XDR incidents, identities, endpoints, cloud resources, and automated response in one experience. New designs should avoid process assumptions that depend on a single legacy portal layout.
The durable part of the architecture is the operating model: governed data sources, normalized schemas where useful, validated detections, clear ownership, reliable entity context, and measurable response outcomes. Technology will continue to change. A Sentinel strategy is successful when the SOC can add a new data source, retire an old connector, tune a detection, or move an investigation workflow without losing the ability to explain what evidence exists and why it matters.
Finally, document architectural decisions separately from portal procedures. A runbook may say where to click today, but the strategy should explain why a source is retained, why a rule is high severity, and which control is expected to contain the threat. That design record survives product navigation changes and helps new analysts understand the security reasoning behind the implementation.
Review the strategy quarterly with both platform and SOC teams. New Microsoft features, connector changes, license shifts, and business systems can change which data is valuable. A living data-and-detection architecture should be able to explain what changed, why the change matters, and which detection or response capability depends on it.