Diagnostic Settings

Expanded Definition

Diagnostic Settings are a cloud logging configuration that determines which platform telemetry is exported, where it is sent, and whether it is retained for later investigation. In Azure, that usually means platform logs and metrics flowing to destinations such as Log Analytics, Event Hub, or Storage, creating the audit trail needed for security monitoring and forensic review. The concept is narrower than general observability because it is specifically about capturing provider-generated signals rather than application instrumentation.

For security teams, Diagnostic Settings sit at the boundary between operations and assurance. They do not detect threats by themselves, but they make detection possible by preserving evidence from subscriptions, resources, and managed services. Their value is strongest when paired with collection, retention, and review requirements that mirror the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls. Usage in the industry is still evolving because teams sometimes treat the feature as a compliance checkbox rather than an operational control layer.

The most common misapplication is enabling Diagnostic Settings on only a few high-profile resources, which occurs when teams assume the platform will automatically preserve complete evidence across the environment.

Examples and Use Cases

Implementing Diagnostic Settings rigorously often introduces log-volume and cost-management constraints, requiring organisations to weigh broader evidence capture against retention, query, and storage overhead.

• A cloud security team routes subscription activity logs to Log Analytics so investigators can reconstruct admin actions after a suspicious privilege change.
• An operations group sends resource metrics to Storage for long-term trend analysis while reserving higher-cost analytics pipelines for active incidents.
• A detection engineering team forwards platform events into Event Hub so a SIEM can correlate Azure activity with identity and endpoint alerts.
• A regulated business enables logging on key workloads to support auditability and align evidence collection with the control intent described in NIST SP 800-53 Rev 5 Security and Privacy Controls.
• An incident responder verifies whether Diagnostic Settings were disabled or misdirected after an alert, because missing telemetry can change the scope of containment work.

Why It Matters for Security Teams

Diagnostic Settings matter because a cloud environment without durable telemetry is difficult to defend, audit, or investigate. When logs are absent, incomplete, or routed to the wrong destination, security teams lose visibility into control-plane activity, and that gap can hide privilege escalation, policy tampering, or lateral movement. For governance, the key question is not simply whether logging exists, but whether it is reachable by the right tools, retained long enough, and protected from alteration.

This is also where identity and access concerns intersect with cloud operations. If an attacker compromises an account that can modify diagnostic routes, they can reduce detection coverage or suppress evidence, turning a logging control into a blind spot. That is why Diagnostic Settings should be treated as part of a larger control set that includes access restriction, monitoring, and retention discipline, consistent with the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls. Organisations typically encounter the operational impact only after an incident review reveals missing telemetry, at which point Diagnostic Settings become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do legacy authentication settings create ongoing identity risk?
• When should organisations treat SaaS settings as an IAM issue?
• When do SaaS sharing settings become a real security risk?
• How should security teams govern shared AI agents that can inherit hidden proxy settings?