A naming convention for policies

Names that convey purpose, scope and control without opening the policy.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Policy naming convention

benchmark guidance does not prescribe one. Microsoft does specify what a name must convey, and the

scheme below implements it. The agent's "inconsistent naming" finding (Low severity) needs

something concrete to recommend instead of a complaint.

Microsoft's requirement

A policy name should let you understand it without opening it, showing:

1. A sequence number — so admins can say "open CA01" on a phone call
2. The cloud apps it applies to
3. The response (the control)
4. Who it applies to
5. When it applies (the conditions)

Microsoft also notes that Conditional Access policies have no built-in owner attribute.

Ownership must be encoded in the name (e.g. a team prefix) and tracked in an out-of-band

registry mapping each policy to a responsible admin or team. The registry is not optional —

it is the only place ownership can actually live.

Pattern

CA<nnn>-<Persona>-<Resource>-<Control>[-<Condition>][-Report]

Number blocks

Grouping by number band makes the estate readable at a glance and leaves room to grow:

Contingency policy naming — Microsoft's scheme

For the disabled/report-only policies held in reserve for an outage:

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

ENABLE IN EMERGENCY goes at the start so the policy stands out in a list of 200. The

[i/n] sequence tells an administrator, mid-incident, what order to enable them in.

Microsoft's own example:

EM001 - ENABLE IN EMERGENCY: MFA Disruption[1/4] - Exchange SharePoint - Require Microsoft Entra hybrid join
EM002 - ENABLE IN EMERGENCY: MFA Disruption[2/4] - Exchange SharePoint - Block access except Windows
EM003 - ENABLE IN EMERGENCY: MFA Disruption[3/4] - Exchange SharePoint - Block access except Corporate Network
EM004 - ENABLE IN EMERGENCY: MFA Disruption[4/4] - Exchange - Block EAS for all users

Microsoft-managed policies

These are named Microsoft-managed: <name> and cannot be renamed or deleted. Do not

attempt to bring them into a house naming standard — the prefix is useful anyway, because it

filters cleanly in the audit log. Note them in the policy registry as Microsoft-owned.

Worked examples against the baseline

Level 2 additions: CA103-Admins-AllResources-PhishResistant,

CA403-AllUsers-AllResources-Block-HighRisk,

CA501-AllUsers-AllResources-Block-Untrusted,

CA303-AllUsers-M365Core-TokenProtection.

Description field

The name says what. The description must say why, and carry the accountability that

makes exclusion review possible. Required content:

Purpose:      <the security outcome, one line>
benchmark guidance:          <section number, or "beyond benchmark guidance">
Owner:        <team or role, not a person's name>
Created:      <YYYY-MM-DD>
Report-only:  <start> to <end>
Enforced:     <YYYY-MM-DD>
Exclusions:   <who, why, review date>
Change ref:   <ticket>

The Exclusions line is the one that matters. Every finding of "temporary exclusions that

became permanent" traces back to an exclusion with no recorded reason and no review date.

Migration advice

Renaming a policy does not change its behaviour or its GUID, so renaming is safe. But:

• Existing runbooks, alert rules and documentation reference the old names — update them

in the same change.

• Rename in one batch, not gradually. A half-renamed estate is harder to read than a

consistently badly-named one.

• Record the old-to-new mapping for anyone reading historical sign-in logs, which retain

the name as it was at the time of the sign-in.