Service Control Policy
also called SCP, Azure Policy, Organization Policy
An organisation-level guardrail that limits what any identity in an account may do, regardless of the permissions granted within that account.
The distinction that makes it powerful: ordinary IAM policies grant permissions; a service control policy sets the maximum available. Even an account administrator cannot exceed it, which makes it the only control that survives a compromised or careless account owner.
Typical uses, which are also good examples of preventive rather than detective control: denying use of regions outside those approved (which shrinks the attack surface and simplifies compliance scope); preventing deletion of audit logs and security configuration; requiring encryption on resource creation; blocking the disabling of security services; and preventing the root user from taking certain actions.
Two operational cautions. Guardrails are easy to make too tight, and a denial from an SCP is frequently confusing to debug because the account's own IAM appears to permit the action — error messages rarely say which layer refused. Roll out to a test organisational unit first.
And they are not a substitute for least privilege: an SCP bounds the maximum, while IAM still has to grant the minimum. An account with a permissive SCP and a wildcard role is not protected.
Applied at organisational-unit level, they are what makes a landing zone's guarantees actually hold rather than being conventions.