Why Your Sentinel Logs Are the Best Audit Evidence You're Not Using
Your Sentinel workspace contains years of structured security telemetry that proves control operation, but your compliance team doesn't know it exists.
Your Microsoft Sentinel workspace has been ingesting security logs for months, possibly years. Every sign-in event, every privilege escalation, every configuration change, every threat detection, every incident response action. It's all there. Structured, timestamped, queryable.
Your auditor shows up and asks: "Can you demonstrate that privileged access is reviewed quarterly?" Your compliance analyst opens a separate spreadsheet, finds the last access review export from three months ago, and uploads a PDF. Meanwhile, Sentinel has a continuous record of every PIM activation, every access review completion event, every conditional access evaluation for the past 12 months. Structured data with full context. Sitting unused.
The gap between what Sentinel knows and what your compliance team collects is enormous. Let's close it.
What Sentinel actually contains
Sentinel isn't just a SIEM. It's a normalized, queryable repository of security-relevant events from across your entire estate. The data arrives from dozens of connectors and lands in standardized tables. Here's what's compliance-relevant in those tables.
SigninLogs. Every authentication event. User, application, device, location, conditional access policies evaluated, MFA method used, risk level, result. This table alone proves: authentication controls are enforced, MFA is active, risky sign-ins are blocked, conditional access policies are operating.
AuditLogs. Every directory change. User provisioning, group membership modifications, role assignments, application consent grants, policy changes. This proves: identity lifecycle management is operating, least privilege is enforced, changes are authorized.
SecurityAlert. Every alert generated by Defender products. Threat type, severity, affected entities, detection source, response status. This proves: threat detection controls are active, alerts are generated, incidents are triaged.
SecurityIncident. Every incident created from correlated alerts. Status, classification, assignment, resolution time, response actions taken. This proves: incident response procedures are followed, incidents are classified and resolved.
AzureActivity. Every Azure resource operation. Resource creation, deletion, modification, policy assignment, role assignment. This proves: infrastructure changes are logged, administrative actions are attributed.
InformationProtectionLogs. Every sensitivity label application, DLP policy match, classification action. This proves: data classification controls are active, data loss prevention is operating.
IdentityInfo. User attributes, risk scores, account status changes. This proves: identity governance is maintained, account lifecycle is managed.
Each of these tables is a continuous, structured record of control operation. Not a point-in-time snapshot. Not a manually exported report. A living, queryable evidence base.
Mapping Sentinel tables to control frameworks
Here's where it gets concrete. Specific Sentinel tables map directly to specific control requirements across major frameworks.
Identity controls (ISO 27001 A.8.5, SOC 2 CC6.1, NIST CSF PR.AC-1)
KQL query:
SigninLogs
| where TimeGenerated > ago(90d)
| where ConditionalAccessStatus == "success"
| where AuthenticationRequirement == "multiFactorAuthentication"
| summarize MFAEnforcements = count(), UniqueUsers = dcount(UserPrincipalName) by bin(TimeGenerated, 1d)
This query produces a 90-day record showing MFA enforcement is active daily, how many authentications required MFA, and how many unique users were affected. That's not a screenshot of a conditional access policy configuration. That's proof the policy is enforcing, every day, across your entire user population.
Incident response controls (ISO 27001 A.5.24-A.5.28, SOC 2 CC7.3-CC7.5, NIST CSF RS.AN)
KQL query:
SecurityIncident
| where TimeGenerated > ago(90d)
| summarize
TotalIncidents = count(),
AvgResolutionHours = avg(datetime_diff('hour', ClosedTime, CreatedTime)),
ClassifiedCount = countif(Classification != "Undetermined")
by bin(TimeGenerated, 7d)
This shows weekly incident counts, average resolution time, and classification rates. An auditor asking "do you have an incident response process?" now gets quantitative proof: X incidents per week, Y-hour average resolution, Z% classified. That's more compelling than a policy document and a handful of redacted incident reports.
Configuration management controls (ISO 27001 A.8.9, SOC 2 CC6.1, NIST CSF PR.IP-1)
KQL query:
AzureActivity
| where TimeGenerated > ago(90d)
| where OperationNameValue has_any ("Microsoft.Authorization/policyAssignments", "Microsoft.Compute/virtualMachines/write", "Microsoft.Network/networkSecurityGroups/write")
| summarize ConfigChanges = count(), UniqueOperators = dcount(Caller) by bin(TimeGenerated, 7d)
Configuration changes logged, attributed, timestamped. Every week. The control isn't just "we have a change management process." The control is operating, and Sentinel proves it.
Data protection controls (ISO 27001 A.8.10-A.8.12, SOC 2 CC6.7, NIST CSF PR.DS)
KQL query:
InformationProtectionLogs
| where TimeGenerated > ago(90d)
| summarize
LabelsApplied = count(),
UniqueDocuments = dcount(ObjectId),
DLPMatches = countif(Activity == "DLPPolicyMatch")
by bin(TimeGenerated, 7d)
Weekly data classification activity. Labels applied, documents classified, DLP policies triggered. This demonstrates that data protection controls are active and generating results, not just configured.
Access review controls (ISO 27001 A.5.18, SOC 2 CC6.2-CC6.3, NIST CSF PR.AC-4)
KQL query:
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName has_any ("Access Review", "Remove member from role", "Add member to role")
| summarize ReviewActions = count() by OperationName, bin(TimeGenerated, 30d)
Access reviews completed, role assignments modified, privilege changes tracked. Monthly proof that access governance is operating.
Why log-based evidence is superior to screenshots
There are five specific reasons why Sentinel-sourced evidence is better than what most compliance teams collect.
1. Temporal coverage. A screenshot shows a point in time. A Sentinel query shows a continuous period. An auditor asking about Q3 control operation gets 90 days of daily data points, not a single screenshot from September 15.
2. Metadata integrity. Every Sentinel record carries system-generated metadata: TimeGenerated, TenantId, SourceSystem, Type. This metadata is immutable and system-generated. It can't be fabricated by taking a screenshot of a different environment.
3. Reproducibility. Any auditor with appropriate access can run the same KQL query and get the same results. The evidence is verifiable. A screenshot is "trust me, this is what I saw."
4. Granularity. A screenshot of the Conditional Access overview page shows that policies exist. A SigninLogs query shows that those policies enforced MFA 47,000 times last quarter across 1,800 unique users with a 99.7% success rate. The second version answers follow-up questions the screenshot can't.
5. Freshness. Sentinel data is current to within minutes. You can produce evidence that's hours old, not months old. When your auditor asks about current state, you can answer with today's data.
How Kyudo queries Sentinel directly
Kyudo's integration layer connects to your Sentinel workspace through the Log Analytics API with reader permissions delegated via your Entra ID. It runs predefined KQL queries mapped to specific control requirements, and each query result becomes a structured evidence artifact.
The workflow:
1. Query execution. Kyudo maintains a library of compliance-mapped KQL queries. Each query targets a specific Sentinel table and extracts data relevant to a specific set of control requirements. Queries run on a configurable schedule (daily, weekly, or on-demand for audit preparation).
2. Result structuring. Raw query results are processed into evidence artifacts. Each artifact includes: the KQL query that produced it (reproducibility), the execution timestamp, the result set, summary statistics, and the workspace identifier. No information is lost in translation.
3. Provenance recording. Every evidence artifact records its lineage: which Sentinel workspace, which query, what time range, what authentication context. An auditor can trace from any compliance assertion back to the exact data that supports it.
4. Control mapping. The Compliance Graph knows which controls each Sentinel-sourced artifact attests to. A SigninLogs MFA enforcement query maps to ISO 27001 A.8.5, SOC 2 CC6.1, NIST CSF PR.AC-1, and whatever industry-specific framework requirements apply. One query, multiple control attestations.
5. Freshness scoring. Each evidence artifact has a freshness timestamp. When Kyudo's Controls Hub shows a control's evidence status, it reflects how recent the underlying Sentinel data is. Stale evidence is flagged automatically. No calendar reminders. No "time to re-collect" emails.
6. Gap identification. When a control requirement has no Sentinel query mapped to it, or when a query returns insufficient data, the gap is visible immediately. Your team knows exactly which controls need additional evidence sources, and which Sentinel tables might provide coverage with a new query.
What auditors actually say about log-based evidence
Auditors who've reviewed Sentinel-sourced evidence through Kyudo consistently report three things:
First, the temporal coverage eliminates "point-in-time" objections. When evidence shows daily control operation over 90 days rather than a single screenshot, the "this could have been configured just for the audit" concern disappears.
Second, the reproducibility increases confidence. When an auditor can see the exact query that produced the evidence and understands that anyone with workspace access could run it again, the trust level is fundamentally different from a screenshot.
Third, the metadata reduces follow-up questions. Traditional evidence review generates questions: "When was this collected? From what environment? Is this current?" Sentinel-sourced evidence answers these questions structurally through system-generated metadata.
The 90% you're leaving on the table
Most organizations using Sentinel for security operations are using approximately 10% of its compliance value. They might pull a quarterly incident summary or export a sign-in report for their auditor. But the daily, continuous, structured proof that controls are operating goes uncollected.
Consider what a comprehensive Sentinel integration captures versus what most teams collect manually:
| Control Area | Manual Collection | Sentinel-Sourced |
|---|---|---|
| MFA enforcement | Screenshot of CA policy configuration | 90 days of daily enforcement counts across all users |
| Incident response | 3-5 redacted incident reports | Full incident lifecycle data: detection, triage, resolution, classification |
| Access reviews | PDF export of last quarterly review | Continuous PIM activation logs + review completion events |
| Change management | Selected change tickets | Every Azure resource modification with operator attribution |
| Data classification | Screenshot of Purview label summary | Daily label application counts, DLP trigger rates |
| Monitoring | Screenshot showing Sentinel is running | Detection rule hit rates, alert volumes, coverage metrics |
The manual column is what your auditor sees today. The Sentinel-sourced column is what's available in your workspace right now.
Your Sentinel compliance audit
1. Check your retention. Open your Log Analytics workspace. Verify that SecurityEvent, SigninLogs, AuditLogs, and SecurityAlert tables retain at least 90 days of data. If your retention is shorter than your audit period, you're losing evidence.
2. Inventory your connectors. In Sentinel, check which data connectors are active. Each active connector is a potential evidence source. Azure AD (Entra ID), Microsoft 365, Defender for Cloud, Azure Activity, and Information Protection are the high-value ones for compliance.
3. Run the MFA query. Take the SigninLogs KQL example above and run it against your workspace. If it returns results showing daily MFA enforcement, you have evidence your compliance team probably isn't using.
4. Count your manual evidence items. In your current GRC tool, count how many evidence items were collected via screenshot or manual export from systems that also send logs to Sentinel. Each one is a candidate for replacement.
5. Calculate your coverage gap. Compare the list of controls requiring evidence in your next audit against the list of Sentinel tables that contain relevant data. The overlap is your untapped governance value.
Kyudo connects to your Sentinel workspace via Log Analytics API and runs compliance-mapped KQL queries on schedule. Each result becomes a hashed, timestamped evidence artifact with full provenance and automatic control mapping.
Book a demo to see your Sentinel logs translated into structured audit evidence.
