Service Control Policy

A service control policy sets the maximum permissions available inside an account, enforced from the organization hierarchy above it. AWS describes it as “central control over the maximum available permissions for the IAM users and IAM roles in your organization.” Other clouds solve the same problem with their own policy mechanisms; the properties below are from the AWS documentation, checked in September 2026, because it states them most explicitly.

It restricts and never grants

This is the property that causes the most confusion, and the documentation leaves no room for it: “SCPs do not grant permissions to the IAM users and IAM roles in your organization. No permissions are granted by an SCP. An SCP defines a permission guardrail, or sets limits, on the actions that the IAM users and IAM roles in your organization can perform.”

What a principal can actually do is the overlap: “the logical intersection between what is allowed by the SCP and resource control policies (RCPs) and what is allowed by the identity-based and resource-based policies.” That cuts both ways in practice.

• A permissive policy does not give anyone anything. “A user without any IAM permission policies has no access, even if the applicable SCPs allow all services and all actions.”
• A local administrator cannot override it. An action blocked above the account cannot be used “even if the account administrator attaches the AdministratorAccess IAM policy.”

So this is a ceiling, and least privilege remains a separate exercise underneath it. The guardrail decides what is possible; identity policies decide what is granted.

Inherited, cumulative, and binding on root

Policies attach at levels of the hierarchy and compound downward: “any account has only those permissions permitted by every parent above it.” A permission blocked anywhere above — explicitly denied, or simply not allowed — is unavailable below.

Within a member account the reach is unusual and it is what makes these a real boundary: they apply to everyone “including the member account’s root user.” Most access controls can be undone by a sufficiently privileged local identity; this one cannot.

Where a permissions boundary is also in play, all three layers must agree — “the boundary, the SCP, and the identity-based policy must all allow the action” — which is worth knowing before debugging an access denial across three systems.

The exceptions, and what they imply

The exceptions are documented, and they are not all of the same kind — an account can sit outside the mechanism, a role can, and something that looks like an exemption can turn out not to be one. Mixing them up is common and produces the wrong conclusion in both directions.

Kind	Covered?	What the documentation says
The management account	No	“SCPs don’t affect users or roles in the management account. They affect only the member accounts in your organization”
A member account acting as a delegated administrator	Yes	Being a delegated administrator is not an exemption: “this also means that SCPs apply to member accounts that are designated as delegated administrators”
Service-linked roles	No	Policies “do not affect any service-linked role” — these exist so other services can integrate with the organization and “can’t be restricted by SCPs”
Everyone else in an attached account	Yes	“SCPs affect all users and roles in attached accounts, including the root user”

The management-account gap is the one with design consequences: the account at the top of the hierarchy is the one your guardrails do not constrain. That argues for keeping almost nothing in it, restricting who can use it by other means, and recording its use where someone reads it, which is what an audit log is for. What it does not argue for is treating delegated administration as a hole — that account is bound like any other member account, so a guardrail that would block a security tool’s own actions blocks them there too.

Alongside those, the documentation lists specific tasks that cannot be restricted this way — actions by the management account, anything using a service-linked role’s permissions, registering for the Enterprise support plan as the root user, and a handful of others. Read that list before designing a control that depends on total coverage, rather than discovering the gap from an audit finding.

Rolling one out without locking people out

The documentation’s warning is unusually direct: “AWS strongly recommends that you don’t attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts.” The suggested approach is to create an organizational unit and move accounts into it “one at a time, or at least in small numbers.”

There is one specific way to break everything, worth stating because it is easy to do while tidying up: removing the default full-access policy without replacing it. “You should not remove the FullAWSAccess policy unless you modify or replace it with a separate policy with allowed actions, otherwise all AWS actions from member accounts will fail.”

For deciding what a policy should actually say, the documentation points at evidence rather than intuition: service last accessed data shows which permitted services accounts never use, which lets you tighten a policy toward what is actually needed instead of guessing.

What to put in one

The failure modes are symmetrical. Too broad and it blocks work, collects exceptions, and eventually means nothing. Too narrow and it prevents nothing the organization cared about.

The filter I would apply: reserve these for the rules you would not negotiate under deadline pressure. Typically that is a short list — regions where resources may not be created, logging and audit trails that may not be disabled, a handful of actions nobody should perform anywhere, and services the organization has decided not to use. Everything else belongs in identity policies, where an exception is a local decision rather than a change to the foundation.

Because these are configuration with organization-wide effect, they belong under version control and review — policy as code — and each one needs an owner who can say why it exists, since a guardrail nobody owns accumulates exceptions until it is decoration.

How guardrails fit with the account hierarchy, identity, network topology, and cost allocation is worked through in Before the First Workload.

Reference: AWS Organizations User Guide, Service control policies (SCPs).