A Conditional Access policy that even the help desk understands
A first-principles tour of a Conditional Access policy that's restrictive enough for compliance, lenient enough that the help desk isn't drowning, and self-documenting enough that the auditor can read it without a translator.
The shortest version of this post: a Conditional Access policy is a sentence. Block, with these exceptions, when these conditions hold. If your policy doesn’t read like a sentence, your auditor and your help desk are about to disagree.
Start with the sentence
Write the sentence first. Mine looks like this:
Block sign-ins to Microsoft 365 from outside the UK, unless the user is in the
cap-travelgroup and is using a compliant device.
That’s the whole policy. Everything from here is implementation.
The exceptions list isn’t optional
A policy without exceptions is a policy you’ll relax under pressure on a Friday. Bake the relaxation in from day one — give it a name (cap-travel), a duration (90 days, then re-attest), and an audit trail. The exception is part of the contract; treat it that way.
# Re-attest cap-travel every quarter; the report is dull and that is the point.
Get-MgGroupMember -GroupId $capTravel.Id |
Select-Object DisplayName, UserPrincipalName, AdditionalProperties |
Export-Csv -Path "./cap-travel-$(Get-Date -Format yyyy-MM).csv" -NoTypeInformationThe help desk test
Show the policy to one help desk engineer who wasn’t in the design meeting. If they can predict what will and won’t be blocked, you’re done. If they can’t, the sentence isn’t tight enough — go back to it.
That’s the policy. The rest is just clicks in the portal.