Microsoft Sentinel can only detect, investigate, and automate against data that reaches the right tables with enough fidelity and at an acceptable cost. Data ingestion is therefore not a plumbing task that sits below security operations. Connector choice, collection scope, transformations, latency, retention, and table design directly affect what an analyst can see and what an analytics rule can detect.
The Microsoft SC-200 objectives effective July 28, 2026 include Microsoft Sentinel data configuration and investigation. Microsoft has announced a further English-objective update for October 21, 2026, which is still upcoming as of October 17; check the SC-200 skills measured for the scheduled exam language. The useful skill is understanding how evidence moves from a source into the security platform and where to reduce noise without deleting the telemetry that a future investigation may need.
Start with the security question, not the connector list
A common deployment mistake is enabling every available connector because more data appears safer. More data can improve coverage, but it also creates ingestion cost, storage volume, parsing complexity, duplicated events, and analyst noise.
Begin with the detection and investigation questions the SOC needs to answer. Identity investigations may require sign-in, audit, risk, and directory-change events. Endpoint investigations need process, network, file, and alert telemetry from the endpoint stack. Network investigations may need firewall, proxy, DNS, VPN, or flow data. Cloud investigations need control-plane and workload logs that reveal identity, configuration, and activity.
Map each question to a source, required fields, latency expectation, and retention need. Then select the collection path. This keeps ingestion tied to operational evidence rather than treating the workspace as an undifferentiated log archive.
Use Content hub and data connectors deliberately
Microsoft Sentinel data connectors are commonly deployed through solutions in the Content hub. A solution can include connectors, analytics rules, workbooks, parsers, hunting queries, and other content that is designed around a product or data source.
The connector is the supported onboarding path for many Microsoft and third-party sources. Some connectors integrate directly with Microsoft services; others use agents, APIs, event streaming, syslog, Common Event Format, or custom collection patterns. The configuration experience varies because the source systems differ.
Do not assume that installing a solution means data is flowing. After configuration, verify the expected table receives events, confirm timestamps and key fields, and test that representative events arrive. A green connector status is useful, but a query against the actual destination table is stronger evidence that collection works.
For custom products, decide whether the source can use an existing maintained connector, the Logs Ingestion API, an event-streaming path, or another documented integration. Avoid building a one-off collector when a supported connector already solves the same problem. Custom ingestion code becomes part of the security pipeline and therefore needs authentication, monitoring, schema control, retry behavior, and an owner who will maintain it when the source API changes.
AMA and data collection rules shape collection
For many infrastructure and security telemetry scenarios, the Azure Monitor Agent (AMA) and data collection rules (DCRs) define what is collected and where it is sent. DCRs can scope data streams and, in supported scenarios, apply transformations before ingestion.
That creates an important design point: collection policy is no longer only an agent setting. A DCR can determine which facilities, severities, event IDs, or streams reach the workspace. For syslog and CEF designs, collection architecture, forwarders, agent health, and DCR scope all affect visibility.
When telemetry is missing, troubleshoot the entire path: source generation, forwarder or host configuration, network reachability, AMA health, DCR association and filters, destination workspace, and table query. A failed query does not prove the source produced nothing; the event may have been filtered or routed incorrectly earlier in the pipeline.
Use a known test event when troubleshooting. Generate one event whose time and content you can recognize, then follow it through the pipeline. This makes it easier to distinguish “the source never emitted it” from “the collector dropped it” and “the event arrived but the query looked in the wrong table.” Controlled test evidence is usually faster than guessing from aggregate volume charts or connector status pages.
Ingestion-time transformations can reduce noise safely
Supported ingestion-time transformations let organizations filter or reshape data before it is stored. This can reduce cost and normalize fields, but transformations should be treated as production code because they can permanently remove evidence.
A useful filter removes records the organization has deliberately classified as low-value, redundant, or out of scope. A dangerous filter removes fields or event classes simply because nobody currently queries them. Security investigations routinely depend on details that were not part of the original detection use case.
Before filtering, establish the security owner, expected savings, affected detections, and rollback plan. Test transformations with real sample data. After deployment, monitor ingestion volume and validate that analytics rules, hunting queries, workbooks, and incident investigations still receive the fields they expect.
Table choice affects cost and analytical capability
Microsoft Sentinel and Log Analytics support different table and retention behaviors depending on configuration and data type. Security teams should understand which telemetry requires frequent interactive analytics and which data is primarily retained for occasional investigation or compliance.
The design should consider query frequency, detection dependency, ingestion volume, retention period, and response-time requirements. High-value identity and endpoint telemetry often belongs in the analytical path used by detections. Very high-volume evidence may need tighter filtering, shorter interactive retention, or another tiering approach depending on the organization’s architecture.
The general SIEM model is useful here: centralization only creates value when the data remains searchable and correlated. A workspace full of expensive telemetry with no clear detection or investigation use is not automatically a better SIEM.
Workspace architecture also affects ingestion design. Some organizations centralize security data in one workspace; others need multiple workspaces for residency, business boundaries, scale, or delegated administration. Multi-workspace designs increase the importance of consistent connector deployment, schema standards, cross-workspace hunting strategy, and clear ownership of which SOC is responsible for each source. Collection decisions should be made with the eventual investigation boundary in mind.
Normalize fields when multiple products describe the same event
Different vendors use different field names and schemas for similar security concepts. One firewall might record a source address in one column, another uses a different field, and a cloud product may represent the same concept through nested JSON.
Microsoft Sentinel supports normalization approaches, including parsers and schema models such as ASIM, to make cross-source analytics more consistent. Normalization is particularly useful when a hunting query or detection should work across several products without carrying vendor-specific logic in every branch.
Normalization does not eliminate source-specific detail. Preserve the original evidence and understand which normalized fields are derived. When troubleshooting a detection, analysts should be able to move from the common schema back to the native event to verify what the source actually reported.
Monitor latency, gaps, and connector health
Security data has a freshness requirement. A connector that delivers events hours late may be technically functioning while still undermining near-real-time response.
Track the difference between source event time and ingestion time for important feeds. Establish acceptable latency for identity, endpoint, firewall, cloud-control, and other critical sources. Monitor for sudden volume drops, unexpected spikes, schema changes, authentication failures, expiring API credentials, or agent outages.
A healthy ingestion program also identifies silent failure. If a source normally sends thousands of events per hour and suddenly sends none, the absence itself should generate attention. Data-pipeline monitoring belongs in SOC operations because every downstream rule depends on it.
Control cost without destroying investigation value
The largest ingestion bill is not always caused by the most valuable source. Verbose application, network, or audit streams can dominate volume while only a small subset of fields supports detections.
Use source-side filtering, connector configuration, DCR scope, transformations, and retention choices to control volume, but make changes with evidence. Measure which tables drive cost, which rules and hunts consume them, and which event classes are actually used during incidents. Reducing duplicate ingestion is often safer than eliminating an entire security source.
Cost governance should also include ownership. The SOC, cloud platform team, application owners, and finance stakeholders may all need visibility into why a high-volume feed exists. A security team can defend ingestion spend more effectively when each major source has a documented detection and investigation purpose.
Build for the Defender portal operating model
Microsoft Sentinel is moving to the Microsoft Defender portal as the long-term operating interface. Microsoft states that after March 31, 2027, Sentinel will no longer be supported in the Azure portal. New procedures should therefore account for the unified security-operations experience even while some organizations still use both portals during transition.
The underlying ingestion principles remain stable: connect the right sources, collect the right evidence, validate delivery, control cost, and monitor the pipeline. The portal change matters because analysts increasingly investigate Sentinel data beside Microsoft Defender XDR incidents, advanced hunting, identities, devices, and other security signals.
A strong ingestion architecture is one where analysts can explain where an event came from, how it was transformed, which table stores it, how fresh it is, what it costs, and which detections or investigations depend on it. That traceability is more valuable than simply counting how many connectors are enabled.