Subscriptions should have a contact email address for security issues

What does the recommendation "Subscriptions should have a contact email address for security issues" check?

Flags any subscription where Microsoft Defender for Cloud has no security contact email address recorded, so high-severity alerts and Microsoft's own notifications have nowhere to land. The check looks at the subscription's security contact (the Microsoft.Security/securityContacts resource named 'default') and confirms only that at least one email address is present. It does not verify the address belongs to a monitored mailbox, that the mailbox is still active, or that anyone reads it. It also says nothing about the related settings on the same contact: the phone number, the alert-notification severity threshold, and whether notify-by-role is enabled are all out of scope, so a subscription can pass this control while every other notification lever stays switched off.

Why does "Subscriptions should have a contact email address for security issues" matter?

Defender for Cloud detects compromise in near real time, but a detection nobody reads is worthless. With no contact email, alerts about an active intrusion, a leaked storage key or anomalous data egress sit silently in the portal while the attacker keeps working, and Microsoft has no way to reach you when it spots abuse from your own resources. The business consequence is longer dwell time: the gap between breach and response stretches from minutes to whenever someone next happens to open the console, which is often after the damage is done, credentials have spread, and statutory breach-disclosure clocks have already started. For a control this cheap to satisfy, leaving it unset is pure downside, costing you the early warning that turns a contained incident into a reportable one.

How do I fix "Subscriptions should have a contact email address for security issues"?

1. Set a security contact on the subscription via 'az security contact create -n default --emails [email protected]', pointing it at a monitored distribution list or shared mailbox rather than one person's inbox, so cover survives annual leave, handovers and staff turnover. Add more recipients with a semicolon-separated list, not commas, for example --emails '[email protected];[email protected]'. To amend an existing contact later, use 'az security contact update' with the same default name.
2. Decide your notification scope deliberately. The notification levers are JSON objects, not on/off flags: set --alert-notifications '{"state":"On","minimalSeverity":"High"}' (drop minimalSeverity to Medium if your team can absorb the volume) to get the warnings that matter without drowning the channel, and set --notifications-by-role '{"state":"On","roles":["Owner"]}' so everyone holding the named role is reached even if the distribution list lapses. The roles array takes the RBAC roles you want notified, such as Owner, so list each one you intend to cover.
3. Apply the same contact across every subscription and bake it into your landing-zone Bicep or Terraform using the Microsoft.Security/securityContacts resource, then enforce it with the built-in Azure Policy 'Subscriptions should have a contact email address for security issues' (definition 4f4f78b8-e367-4b10-a341-d9a4ad5cf1c7) so newly created subscriptions inherit a contact instead of starting blank.

# 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"