Send Azure Activity Logs to a Log Analytics workspace by creating a diagnostic setting on the subscription or resource scope and selecting the Activity Log category for that workspace. Confirm the setting is applied, then verify events arrive and are retained as expected. Use alerting on administrative changes, policy actions, and failed operations to detect misuse and drift.
What the diagnostic setting does in Azure
Azure Activity Logs are subscription-level control-plane records, so the task is not “turn on a log source” in the guest OS sense. You create a diagnostic setting at the subscription or resource scope, choose the Activity Log category, and send it to the log analytics workspace you want to query. That gives you a central place to search administrative actions, policy activity, and failed operations across Azure.
The practical detail is scope. Subscription Activity Logs capture management-plane events for the whole subscription, while resource-scoped diagnostic settings are used when a specific Azure service also publishes diagnostic data. For this question, the important decision is whether you are collecting the Azure Activity Log itself, or also extending collection to resource diagnostics that support deeper investigation and correlation.
When you route the log stream into a workspace, you are also deciding where the operational evidence will live. The workspace becomes the query and retention layer, so the configuration should be treated as part of your logging architecture rather than as a one-time export task. That is why teams usually standardize the destination workspace, naming, and retention period before they roll this out broadly.
How to verify the data path is working
After you save the diagnostic setting, confirm two things: the setting remains attached to the correct scope, and the workspace actually receives events. A successful configuration in the portal does not by itself prove ingestion. You need to generate or wait for a representative Azure activity event, then query the workspace to confirm the records arrive with the expected category and timestamps.
Validation should also cover retention and visibility. If the workspace keeps the data for less time than your investigation window, the setup is only partially useful. If you rely on the logs for incident response, policy review, or change tracing, confirm that the retention configuration matches how long you need to detect, investigate, and explain administrative actions after the fact.
For operational use, the value is not just storage. The logs become most useful when you can search them by caller, operation name, resource, and status, then correlate those events with other telemetry. That lets you distinguish normal platform change from unexpected drift, and it helps you spot whether a policy change, role change, or resource modification happened when it should not have.
What good monitoring looks like after export is enabled
Once the log stream is in the workspace, build alerts around the changes that matter most: administrative changes, policy assignments or updates, and failed operations that may indicate misuse, misconfiguration, or repeated probing. For Azure environments, this is especially useful because control-plane changes often leave the clearest trail of who changed what, when, and from where.
A strong monitoring pattern is to treat the Activity Log as an audit source, not just a troubleshooting source. That means watching for unexpected subscription changes, unusual bursts of failed management operations, and policy drift that weakens guardrails. If you already have a security operations workflow, route those signals into it so log review does not depend on manual searching after an incident.
This is also where centralization matters. A workspace that only receives logs but is not queried, alerted on, or retained appropriately creates a false sense of coverage. The objective is to make Azure control-plane activity searchable soon after it happens, and durable long enough to support both routine operations and post-incident review.
Risk and Threat Considerations
Control-plane logs are often the first place compromise or misuse shows up, so gaps in collection create blind spots around privilege abuse, policy tampering, and unauthorized administrative change. If the Activity Log is not being forwarded, or if retention is too short, you can miss the trail needed to reconstruct what changed in the subscription.
Failure mechanism: The diagnostic setting is mis-scoped, removed, or pointed at the wrong workspace, so activity events never reach the place where defenders expect to search and alert on them.
Impact: Security teams lose visibility into administrative actions and policy drift, which weakens detection, slows investigation, and makes it harder to prove whether a change was legitimate or malicious.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | LOG — Logging and Monitoring | Azure Activity Log forwarding is core cloud logging and audit trail control. |
| Recommendation — Centralize Azure control-plane logs and retain them for detection and investigation. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The question is about collecting audit events for later review and detection. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Workspace ingestion is useful only when logs are reviewed and acted on. | |
| Recommendation — Define which Azure events must be logged and reviewed. Analyze Azure activity records and alert on suspicious administrative changes. | ||
| NIST CSF 2.0 | DE.CM-08 — Logging and Alerting Activities | Forwarding Activity Logs supports continuous monitoring and alerting. |
| Recommendation — Use collected Azure logs to monitor for drift, misuse, and policy changes. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | The topic is explicitly about configuring security logging and retention. |
| Recommendation — Configure Azure logging so events are collected, retained, and reviewable. | ||
Practitioner Guidance
What to verify: Confirm the setting is applied at the scope that matches your monitoring objective, then test with a known control-plane action and verify the event lands in the workspace you expect. If you cannot query the event soon after the action, treat the configuration as incomplete.
What to prioritize: Alert on the events most likely to matter operationally, especially policy changes, privileged administrative actions, and repeated failures. Those signals usually provide more value than broad noise-heavy alerting on every low-signal event.
Practitioner takeaway: The real control is not just “send logs to a workspace,” it is proving that the log path is scoped correctly, retained long enough, and actually used to detect drift and misuse.
Related resources from NHI Mgmt Group
- Guide: Cloud Logging and Audit Trail Guide
- How should security teams design log ingestion pipelines when they need to send events into ClickHouse and other analytics backends?
- How should security teams simplify analysis of Azure Activity logs when OperationId and CorrelationId do not reliably group related events?
- What happens when teams analyze Azure Activity logs only through the raw command line view?
- How do you access and review activity logs in Microsoft Entra ID?