BigID Sentinel Connector Leaves Schema and Costs Unclear

Technology Record reported on August 11 that BigID is using Microsoft’s Codeless Connector Framework, or CCF, and nested API support to bring deeper context into Sentinel workflows. Jon Mayer, BigID’s vice president of business development and partnerships, told the publication that the aim is to let analysts use BigID’s DSPM findings inside the Microsoft security tools they already operate rather than pivoting into a separate BigID console.

Microsoft’s own Sentinel connector documentation confirms that a BigID DSPM connector exists and is supported by BigID. Microsoft describes its purpose more narrowly: ingesting BigID DSPM cases, affected objects, and data-source information into Sentinel. That narrower official description is important. It confirms the basic integration, but it does not independently promise a full in-console risk-ranking experience or spell out the fields delivered for each case.

For Sentinel administrators, this is useful enrichment rather than a replacement for detection engineering, data classification, or access reviews. It can help answer the question an alert alone often cannot: what data sits behind this event, and who can reach it? But organizations should validate the connector’s output, schema, volume, and cost before treating BigID findings as a new high-confidence priority signal.

The connector’s confirmed data destination​

Microsoft lists

as the Log Analytics table used by the BigID DSPM connector. Its documentation says the connector imports BigID DSPM cases along with affected objects and data-source information, and that it supports Data Collection Rules, including workspace transformation DCRs.

That makes the integration operationally meaningful. A Sentinel analyst can query the BigID table in Kusto Query Language, correlate BigID cases with identity, endpoint, cloud, SaaS, or network telemetry, and build analytics rules or workbooks around the imported records. The result can be a much more specific investigation than a bare alert containing only a user account, IP address, or file operation.

Consider a routine example: a Defender, Entra ID, or third-party SaaS alert indicates anomalous access by a compromised account. The security event may say who performed the action and where it came from, but it usually cannot explain whether the accessible repository held public marketing collateral, HR files, customer payment data, source code, or regulated records. A DSPM data source can supply the missing data estate context, assuming its object identifiers, identities, source references, and classifications can be reliably joined to the security event.

That assumption deserves testing. Different tools often identify the same resource differently: a cloud-storage URL in one product, a tenant-scoped object ID in another, and a display name in a third. Importing cases into a custom table is not the same as supplying ready-made correlation rules. Neither Technology Record’s report nor Microsoft’s connector entry identifies prebuilt analytics rules, ASIM parsers, workbooks, automation playbooks, or entity mappings that ship with the BigID connector.

The CCF claim needs a deployment check​

Technology Record says the new BigID integration is built on Microsoft’s Codeless Connector Framework and uses nested API support. CCF is Microsoft’s partner framework for creating Sentinel connectors that collect data through supported APIs without requiring customers to deploy a traditional agent or virtual machine. Microsoft says its current CCF polling connectors are fully SaaS and include health monitoring.

However, Microsoft’s published BigID connector setup record describes a deployment that creates a Function App, Storage Account, Data Collection Endpoint, Data Collection Rules, and custom Log Analytics tables. It also says data should begin flowing 15 to 30 minutes after deployment. That deployment model is not inherently wrong—Azure Functions are serverless—but it is more infrastructure than the shorthand “codeless connector” may lead a customer to expect.

There are two plausible explanations. BigID may be moving from a function-based implementation to a newer CCF-based connector, with Microsoft’s connector catalog documentation still describing the earlier packaging. Or the implementation may use CCF elements while continuing to provision supporting Azure resources. Neither Technology Record nor the Microsoft documentation published with the connector resolves that point.

This is the first item an administrator should verify in a non-production subscription: whether the Marketplace deployment creates the resources Microsoft currently documents, whether the connector appears as a native CCF connection in the Sentinel data-connector gallery, and whether an existing BigID deployment requires redeployment. The announcement does not state upgrade behavior, coexistence rules, or whether previously ingested cases will be normalized into the same table.

“More context” is valuable only if it changes triage​

The strongest case for the BigID connector is not that it puts another feed into Sentinel. Sentinel environments already contend with a large number of data sources and security findings. The value is whether BigID’s findings can reduce the time spent deciding which events warrant escalation.

Microsoft said at Ignite 2025 that BigID, Cyera, Varonis, and OneTrust integrations were intended to supply third-party data asset information, including permissions, location, and sensitivity, into the Microsoft Purview DSPM experience through Sentinel’s data lake. BigID separately described its Microsoft relationship as extending data discovery and classification across Microsoft and non-Microsoft environments.

Those statements provide useful context for the August report: Microsoft has been building toward a model where its security operations tooling receives data-risk signals from specialist DSPM products. BigID’s connector is part of that larger effort to join operational detections to the data they may expose.

But the integration does not automatically turn every BigID case into an incident that should outrank endpoint, identity, or active-exploitation alerts. Data-risk severity is dependent on the source system’s discovery coverage, classification policies, identity mapping, access graph, and scan cadence. If a sensitive SharePoint site, Snowflake data set, S3 bucket, or on-premises file share is absent from BigID’s scanning scope, Sentinel cannot enrich alerts involving that asset with data that BigID never collected.

The same applies to access risk. A “who can access this” field may describe an entitlement, a group membership path, a public sharing state, a service account, or a stale permission snapshot. It should guide an analyst toward the right owner and investigation path, but it should not be treated as proof that a person accessed or exfiltrated a record. That evidence still comes from identity, audit, cloud, endpoint, and application telemetry.

Cost and data volume are absent from the announcement​

The report says the connector is available through Microsoft Marketplace, while BigID is also available through Microsoft Security Store. It does not provide connector pricing, BigID licensing requirements, ingestion estimates, retention guidance, rate limits, polling intervals, or a data-volume control model.

Microsoft’s documentation does identify one prerequisite: access to the BigID DSPM API through a BigID token. That means customers need an active BigID environment with API access before Sentinel can collect its cases. The connector is not a substitute for BigID licensing, data discovery configuration, or the operational work of maintaining classification and risk policies.

Sentinel ingestion also has a cost consequence. Microsoft bills Sentinel and Log Analytics according to data tier and usage, and some connectors add charges for supporting Azure resources. Even if the connector itself carries no separate Marketplace fee, importing detailed object-level case data can increase Log Analytics ingestion and retention consumption. The more granular the “affected objects” payload becomes, the more important it is to measure what lands in

.

Workspace transformation DCR support gives security teams one way to control that. They can filter unnecessary records or fields before they are retained in the destination table, provided the fields needed for investigation and correlation survive the transformation. The wrong optimization would be stripping object identifiers, source IDs, classification labels, owner fields, and timestamps—the very context the connector is meant to contribute.

What Sentinel teams should validate before relying on it​

A controlled deployment should establish whether the connector improves investigation quality rather than merely expanding the volume of data in Sentinel. Start by identifying a small group of known BigID cases across different data sources and compare the original BigID record with the Sentinel record field by field.

Teams should confirm the following in their own tenant:

• The connector’s deployed resources, connection method, and authentication model match the design approved by the cloud platform team.
• The BigIDDSPMCatalog_CL records include durable identifiers that can be correlated with Microsoft 365, Azure, AWS, Google Cloud, endpoint, and identity events.
• The severity and risk information transferred from BigID is sufficiently documented to support alerting thresholds and analyst runbooks.
• Data Collection Rule transformations preserve investigation-critical fields while limiting avoidable ingestion and retention costs.
• Existing BigID connector installations have a documented upgrade path if the newly reported CCF implementation is a replacement rather than an in-place update.
• At least one Sentinel analytic rule or hunting query demonstrates that the extra data changes a triage decision, escalation path, or containment action.

BigID’s move is credible as a practical answer to a persistent SOC problem: security telemetry often identifies activity before it identifies business impact. Microsoft confirms the connector can bring BigID cases, affected objects, and data-source information into Sentinel. The next step for customers is to prove that the imported fields create reliable correlations and sharper priorities—without quietly adding an unmanaged Azure deployment and a large new ingestion bill.