Compliance

Set a security contact and high-severity alerts

One capability with two halves: make sure Defender for Cloud knows who to email when something goes wrong, and make sure it actually sends an email the moment a high-severity alert fires, so a real breach reaches a human instead of sitting unseen in a console.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-notify-high-severity-alerts azure-notify-subscription-owner-high-severity-alerts azure-security-contact-email

Security contact and alert notifications: the basics

What does a subscription with no security contact actually look like?

Defender for Cloud watches your subscriptions and raises a security alert when it sees something that looks like an attack: a brute-force sign-in, a crypto-mining process, a suspicious storage access, a privilege escalation. The alert is only useful if it reaches a person who can act on it. Two settings decide whether that happens. The first is the security contact: the email address, or set of addresses, that Microsoft notifies when there is a potential security issue on the subscription. The second is alert notifications: the switch that says 'send an email when an alert of this severity or higher fires', set to a minimum severity of High. Each is a separate Defender for Cloud recommendation, but they are one job: make sure a high-severity alert lands in a human's inbox.

Both recommendations map to the same Microsoft Cloud Security Benchmark control, IR-2, which is about preparing to respond to incidents by getting notifications to the right people. 'Subscriptions should have a contact email address for security issues' checks that a contact is set at all. 'Email notification for high severity alerts should be enabled' checks that the notification switch is on and set to notify at High severity or higher. They read as two findings, but a subscription that fails one usually fails the other, because both come from the same empty security-contact configuration.

Most of this gap is omission, not intent. A subscription gets created, workloads get deployed, Defender starts watching, and nobody ever opens the email notifications page to type in a distribution list. By default Microsoft notifies subscription owners about high-severity alerts, but 'owner' is often a person who left, a break-glass account nobody reads, or a service principal with no inbox at all. The work is to set an explicit, monitored contact on every subscription, set the notification threshold to High, and stop relying on whoever happens to hold the Owner role to be watching.

In this lesson you will learn how Defender for Cloud routes security alerts to people, why a subscription can be fully monitored yet notify no one, and how to set a monitored security contact and high-severity alert emails across every subscription and keep them set. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The alert nobody was listening for

A recurring finding in cloud breach post-mortems is that the platform had already raised the alarm. The detection fired, the alert was generated, it was sitting in the security console: and nobody saw it for days because the notification was never wired to a monitored inbox. By default Defender for Cloud emails subscription owners about high-severity alerts, but in real estates the 'owner' is frequently a person who has left the company, a shared break-glass account no one reads, or a service principal with no mailbox at all. The detection was never the weak link. The wire from the detection to a human was.

Finding subscriptions with no security contact

Priya is the security lead at a scale-up running across four Azure subscriptions, preparing for a SOC 2 audit. Defender for Cloud flags 'Subscriptions should have a contact email address for security issues' on two of them, and 'Email notification for high severity alerts should be enabled' on three.

Rather than open each subscription in the portal, Priya reads the security contact configuration straight from the API to see exactly which subscriptions have no contact, and which have a contact but the alert switch turned off or set too low.

Read the security contact on each subscription. An empty email and an Off alert state are the two failure modes you are looking for.

$ az security contact show --name default --query "{emails:emails, alertState:alertNotifications.state, severity:alertNotifications.minimalSeverity}" -o table

Emails AlertState Severity

------------------- ------------ --------

(blank) Off

[email protected] On Low

# Subscription 1 notifies no one. Subscription 2 has a contact but alerts are off.

A blank email with alerts Off is the worst case: a fully monitored subscription that can detect an attack and tell nobody. Fix these first.

How Defender for Cloud decides who to notifydeep dive

Both recommendations resolve to a single object: the security contact at 'Microsoft.Security/securityContacts/default' on the subscription. Its properties decide everything. 'emails' is the explicit recipient list, a set of addresses Microsoft notifies directly. 'notificationsByRole' can additionally notify everyone holding a given Azure role, such as Owner. 'alertNotifications' carries a 'state' of On or Off and a 'minimalSeverity' of Low, Medium or High, which is the threshold at or above which an alert generates an email. The contact-email recommendation passes when 'emails' is populated; the high-severity recommendation passes when 'alertNotifications.state' is On and 'minimalSeverity' is set to High or, since High is the top tier, exactly High.

The default behaviour is the trap. With no explicit configuration, Defender for Cloud still emails subscription owners about high-severity alerts, so it can feel like notifications are handled. But that route depends entirely on the Owner role being held by people who read the inbox it points at. When the Owner is a departed employee, a break-glass account or a service principal, the alert is emailed into the void. Setting an explicit 'emails' value to a monitored distribution list is what turns this from 'whoever happens to be Owner' into 'a team we know is watching.'

Defender for Cloud evaluates these recommendations against the Microsoft Cloud Security Benchmark on a periodic cycle, so a fix does not flip the finding to Healthy instantly. The control-plane change is immediate, but the posture catches up on the next assessment. The strongest position pairs the per-subscription contact with an Azure Policy assignment that audits for the contact and the High-severity switch across every subscription, so a new subscription created without them is flagged the moment it appears rather than discovered at the next audit.

What is the impact of having no security contact?

The direct impact is dwell time. A subscription that detects an attack but notifies no one is one where an incident runs until someone happens to look at the console or notices a downstream symptom. Every credible breach study points the same way: the longer an attacker is in undetected, the more they exfiltrate, the wider they move, and the more the eventual clean-up and notification costs. A high-severity alert that emails a monitored team the moment it fires is the single cheapest way to shrink that window.

The second-order impact is cost and blast radius. A compromised subscription is frequently used to spin up expensive resources, crypto-mining fleets, mass data egress, before it is used to steal anything, so the first visible sign is often a bill anomaly. Wiring high-severity alerts to a human is both your earliest security warning and your earliest financial warning. Without it, you find out from the invoice.

On the compliance side, every modern framework, ISO 27001, SOC 2, NIST and the Microsoft Cloud Security Benchmark control IR-2 this capability maps to, expects evidence that security incidents are routed to identified responders. 'We can detect, but we never told the platform who to tell' is a finding no auditor accepts. A populated security contact and an enabled high-severity alert on every subscription is the cheapest and most defensible incident-response artefact you can produce.

How do you wire alerts to a human, properly?

Work the capability as one loop across every subscription rather than fixing one finding at a time. The order matters: choose a durable recipient before you set anything, so you do not wire alerts to an inbox that will go stale.

1. Choose a monitored recipient, not a person

Set the contact to a security distribution list or a shared mailbox that a team actually watches, ideally one that also feeds a ticketing or on-call system, never a single named individual who can leave. The whole point is that the recipient outlives any one person's tenure and role assignment.

2. Set the contact and enable High-severity alerts on every subscription

Populate 'emails' with the monitored list and set 'alertNotifications' to On with 'minimalSeverity' of High. Do this on every subscription, because the security contact is a per-subscription object: a clean parent does not cover a child subscription. Optionally add 'notificationsByRole' for Owner as a belt-and-braces second route, but never rely on it alone.

3. Confirm an alert actually arrives

A populated contact is necessary but not sufficient: verify the email genuinely lands. Use Defender for Cloud's sample-alert capability or wait for a benign test alert, and confirm it reaches the distribution list and creates a ticket. A contact that is set but bounces is no better than a blank one.

4. Ratchet it shut with Azure Policy

Assign the built-in audit policies so any subscription without a security contact email, or with high-severity alert notifications off, is flagged the moment it appears. This turns 'we set it on the subscriptions we knew about' into 'every subscription, including ones created next month, is checked automatically.'

# Set a monitored security contact and enable High-severity alert emails
# on the current subscription. --alert-notifications and --notifications-by-role
# take a JSON object, not a bare string; the role list lives inside that object.
az security contact create \
  --name default \
  --emails "[email protected]" \
  --alert-notifications '{"state":"On","minimalSeverity":"High"}' \
  --notifications-by-role '{"state":"On","roles":["Owner"]}'

# Apply it across every subscription you can see.
for sub in $(az account list --query "[].id" -o tsv); do
  az account set --subscription "$sub"
  az security contact create --name default \
    --emails "[email protected]" \
    --alert-notifications '{"state":"On","minimalSeverity":"High"}'
  echo "$sub: security contact set, high-severity alerts on"
done

# Ratchet it shut: audit any subscription missing a contact email.
az policy assignment create \
  --name audit-security-contact \
  --policy 4f4f78b8-e367-4b10-a341-d9a4ad5cf1c7 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Quick quiz

Question 1 of 5

Defender for Cloud flags both 'Subscriptions should have a contact email address' and 'Email notification for high severity alerts should be enabled' on the same subscription. What is the most efficient way to think about them?

Keep learning

Go deeper on how Defender for Cloud routes alerts to people and how to keep the security contact set across the estate.

You can now treat the security contact as one capability rather than two stray findings: choose a monitored recipient that outlives any one person, set the contact and enable High-severity alerts on every subscription, confirm an alert actually arrives, and audit for both with Azure Policy so a new subscription is never left silent. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Security contact and alerts: the cost and risk view

A zero-cost control that decides how long a breach runs before anyone notices

Setting a security contact and turning on high-severity alert emails costs nothing in Azure spend. There is no meter, no resource, no per-message charge: it is a configuration value on the subscription. The entire cost of this capability is a few minutes of engineering time per subscription, and the value it buys is dwell time, the gap between a breach starting and someone noticing it.

Frame the failing recommendation as a line on the risk register, not a checkbox. The expected cost of an incident rises with every hour it runs undetected: more data exfiltrated, more resources spun up by an attacker, a longer and more expensive forensic timeline. A subscription with no monitored security contact is one where that clock can run for days before a human looks. The control that closes the gap is free, which makes the trade about as one-sided as security spending gets.

There is a finance-adjacent failure mode worth naming: an attacker who compromises a subscription often spins up expensive resources, GPU fleets for crypto-mining, large data egress, that show up first as a bill shock and only later as a security incident. A high-severity alert that reaches a human early is also the cheapest early warning you have against a runaway compromised-resource bill.

This lesson is for the finance partner who sees a security-contact finding on the report and wants to know what it costs to fix and why it matters. It covers why the control is free in Azure spend, why it nonetheless belongs near the top of the risk register, and how undetected incidents turn into both breach costs and runaway compromised-resource bills.

Fun fact

The alert nobody was listening for

How a finance partner frames the security-contact decision

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with contact and alert findings across three of four subscriptions. The instinct is not to ask for a remediation budget, because there is nothing to buy: setting a security contact and enabling high-severity alert emails costs nothing in Azure spend. It is a configuration value, not a resource. The spend question here is effectively zero, so the finance conversation is entirely about risk and time, not cost.

Priya reframes the findings on the risk register in terms of dwell time. A subscription that detects an attack but emails no one is a subscription where an incident can run undetected for days, and the expected cost of an incident climbs every hour it goes unseen: more data exfiltrated, more attacker-spun resources on the bill, a longer forensic timeline. Priya makes a second, finance-specific point: a compromised subscription with no alerting often shows up first as a bill shock, a sudden GPU fleet or a spike in data egress, before anyone calls it a breach. The finance pack reads: 'This control is free to enable, it is also our cheapest early warning against both an undetected breach and a runaway compromised-resource bill, and there is no budget reason to delay it by a single day.'

Why a missing security contact belongs on the risk register

The cost model here is as asymmetric as security work gets. Enabling the control is free in Azure spend, and leaving it off creates an open-ended tail risk measured in dwell time. Each failing subscription is one where an incident could run undetected, and the expected loss of an incident scales with how long it runs before a human sees it. The probability of a breach on any given subscription in a given week may be low, but the cost of one that runs for days because nobody was notified is not.

The documented cost of a breach includes notification within tight regulatory windows, forensics, legal fees and customer churn, all of which grow with dwell time. There is also a direct, near-term cost finance feels first: a compromised subscription with no alerting can run up a large bill in attacker-spun resources before anyone notices. The finance role is to recognise that a free control sitting on the risk register as 'undetected-incident dwell time' should be closed immediately, because there is no spend trade-off to weigh against it at all.

What finance can do about the security-contact gap

Finance cannot set a contact, but it owns the framing that moves a free, high-value control to the front of the queue and keeps anyone from treating it as a budget item to defer. Three levers.

1. State plainly that the control is free

Make it explicit that setting a security contact and enabling high-severity alert emails costs nothing in Azure spend: there is no resource and no per-message charge, only a configuration value and a few minutes of engineering time per subscription. Removing any perceived cost removes the only excuse to defer it, and stops the finding being parked behind work that does cost money.

2. Put dwell time, not finding count, on the risk register

Frame each failing subscription as undetected-incident dwell time rather than a single red item. The metric that belongs on the cost-and-security review is whether every subscription emails a monitored recipient on a high-severity alert, because that is what bounds how long an incident can run before anyone reacts. Ask for the count of subscriptions where the answer is no, and treat driving it to zero as the goal.

3. Name the compromised-resource bill risk

Connect this control to the cost side directly: a compromised subscription with no alerting often surfaces first as a bill shock, attacker-spun GPU fleets or a spike in egress, days before it is recognised as a breach. A high-severity alert wired to a human is finance's earliest warning against that runaway bill, which makes enabling it a cost-control measure as much as a security one.

Quick quiz

Question 1 of 5

A security report flags a missing security contact on three subscriptions. As the finance partner, what is the right starting assumption about the Azure-spend cost to remediate?

Keep learning

Go deeper on how Defender for Cloud routes alerts to people and how to keep the security contact set across the estate.

You have finished the finance view of setting a security contact. You know the cost model is one-sided to the point of having no spend side at all: the control is free, and the downside of leaving it off is undetected-incident dwell time plus a possible runaway compromised-resource bill. Next time a contact finding lands, you will move it to the front of the queue precisely because there is nothing to budget, and you will track the count of subscriptions that still notify no one until it reaches zero.

Back to the library

Security contact and alerts: the headline

Whether a real security alert reaches a human, or dies unseen in a console

Detection without notification is not detection. Defender for Cloud can spot a genuine attack on your estate, but if no one has told it where to send the email, the alert sits in a console that nobody is staring at. The report surfaces this as a quiet, low-drama finding, which is exactly why it gets left: it is not an open door, it is a silent alarm with no wire to the bell.

The leadership question is simple: if our estate were attacked tonight, would anyone find out before morning? The defensible end state is that every subscription has a monitored security contact, high-severity alerts email a real distribution list rather than a departed Owner, and that this is enforced rather than left to whoever set up the subscription.

This is not a cost decision. Setting a contact and enabling alerts is free in Azure terms. It is a governance decision about whether your detection capability is actually wired up to a human, or whether you are paying for a smoke detector with no battery.

A short read for the leader who needs to know what a missing security contact actually means, why enabling alerts is a governance decision rather than a budget one, and what a defensible, fully-wired end state looks like across the estate.

Fun fact

The alert nobody was listening for

What it looks like when every alert reaches a human, not a console

After reading about a peer company whose breach ran for over a week because the alert had fired but nobody was notified, the CEO asked the obvious question at the next review: if we were attacked tonight, would we find out before morning? The honest answer at the time was that it depended on the subscription. Two of the four had no security contact at all, and a third notified a distribution list that pointed at a team that had been reorganised away.

The team's response was to stop treating the security contact as a per-subscription afterthought and start treating it as wiring that must be present everywhere. They read the contact configuration across every subscription, set a single monitored security distribution list as the contact, set the alert threshold to High, and then assigned an Azure Policy that flags any subscription where the contact or the high-severity alert switch is missing. The next time the CEO asked the question, the answer had changed from 'probably, on most subscriptions' to 'yes, every subscription emails a monitored team the moment a high-severity alert fires, and policy tells us immediately if one ever stops.' That shift, from hoping someone is watching the console to guaranteeing the alarm is wired to a human, is the confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

Why this is a board-level risk

The breaches that do the most reputational damage are rarely the ones that were never detected. They are the ones where the platform raised the alarm and no one was listening, because the question afterwards, 'you knew and did nothing?', is far harder to answer than 'you were caught off guard.' A populated, monitored security contact is what makes the answer 'we were notified and we responded' instead.

The cost of getting this wrong is large and grows with every hour of dwell time, while the cost of fixing it is effectively zero. This is the rare class of control where the risk of inaction is severe and the cost of action is a few minutes of configuration, which is exactly the trade leadership should be quickest to approve and slowest to defer.

The leadership move on alerting

The executive handle is not to approve the fix, there is nothing to approve, it is to require that every subscription is provably wired to a monitored human and to hold the line that this is non-negotiable because it is free.

1. Set a deadline to reach a fully-wired end state

Ask for a date by which every subscription has a monitored security contact, high-severity alerts are enabled across the estate, and Azure Policy audits for both so a new subscription created without them is flagged immediately. A backstop the platform checks automatically is the difference between 'wired on the subscriptions we remembered' and 'wired everywhere, and we will know at once if one ever is not.'

2. Ask for proof the alarm actually rings

The proof is not 'we set a contact.' It is evidence that a test or sample high-severity alert reached the monitored distribution list and raised a ticket, plus a passing set of the two recommendations across every subscription. A contact that is configured but bounces or goes to an unwatched inbox fails silently, so insist the wire is tested end to end, not just present.

3. Insist the recipient is a team, not a person

The leadership requirement is that the contact points at a monitored distribution list or on-call rotation that outlives any individual, not a named employee who can leave or change roles. The single most common way this control quietly fails is a contact that was correct the day it was set and pointed at a departed person a year later. Owned by a team, it stays correct.

Quick quiz

Question 1 of 5

At a board review you ask whether your estate would detect a night-time attack before morning. What end state is the defensible answer?

Keep learning

Go deeper on how Defender for Cloud routes alerts to people and how to keep the security contact set across the estate.

Two takeaways. Setting a security contact is the rare control where the risk of inaction is severe and the cost of action is effectively zero, so it is the trade you should be quickest to approve and slowest to defer. And the defensible end state is not 'we have an Owner on every subscription'; it is a monitored distribution list that receives high-severity alerts on every subscription, tested end to end, with Azure Policy flagging any subscription that ever goes silent.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Defender

Microsoft Defender for Cloud

Email notification to subscription owner for high severity alerts should be enabled Medium Without owner notifications, subscription owners may not learn of a high-severity breach in time to act.

Part of the learning path Turn on Azure detection

Set a security contact and high-severity alerts

Security contact and alert notifications: the basics

The alert nobody was listening for

Finding subscriptions with no security contact

How Defender for Cloud decides who to notifydeep dive

What is the impact of having no security contact?

How do you wire alerts to a human, properly?

1. Choose a monitored recipient, not a person

2. Set the contact and enable High-severity alerts on every subscription

3. Confirm an alert actually arrives

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Security contact and alerts: the cost and risk view

The alert nobody was listening for

How a finance partner frames the security-contact decision

Why a missing security contact belongs on the risk register

What finance can do about the security-contact gap

1. State plainly that the control is free

2. Put dwell time, not finding count, on the risk register

3. Name the compromised-resource bill risk

Quick quiz

Keep learning

Security contact and alerts: the headline

The alert nobody was listening for

What it looks like when every alert reaches a human, not a console

Why this is a board-level risk

The leadership move on alerting

1. Set a deadline to reach a fully-wired end state

2. Ask for proof the alarm actually rings

3. Insist the recipient is a team, not a person

Quick quiz

Keep learning

Controls this lesson covers

Defender

Microsoft Defender for Cloud

Related compliance lessons