A service control policy sets the maximum permissions available to IAM users and roles in the member accounts of an AWS Organization. It never grants access by itself, it does not apply to the management account, and it cannot restrict service-linked roles. Test on a small group of accounts before attaching one to the root.
What an SCP does
SCPs offer central control over the maximum available permissions across your organization. They are a guardrail, not a grant. Real permissions still come from identity-based and resource-based policies, and the effective permission is the intersection of the two.
SCPs are available only when the organization has all features enabled, not consolidated billing alone.
What they do not do
From the AWS documentation:
- They never grant permissions. A user with no IAM permission policy has no access, even when the SCP allows everything.
- They skip the management account. SCPs affect only member accounts, including delegated administrator accounts. This is why AWS advises keeping workloads out of the management account.
- They do not restrict service-linked roles.
- They do not directly change resource-based policies. An SCP applies to principals managed by accounts in your organization, not to outside users. If a bucket in your organization trusts an account outside it, that outside account's users are not bound by your SCP.
- A few tasks are exempt, such as registering for the Enterprise support plan as the root user, and some other root-only items listed by AWS.
What they do very well
SCPs apply to every user and role in an attached account, including the account's root user. If a permission is blocked at any level above the account, nobody in that account can use it, even with an AdministratorAccess policy.
That makes them a good fit for rules like:
- Prevent leaving the organization.
- Deny use of Regions you never use.
- Block turning off audit logging.
- Deny most actions by member account root users.
Deny list or allow list
By default, AWS attaches a FullAWSAccess policy to everything. A deny list SCP keeps that policy and adds explicit denies for what you want to forbid. An allow list removes FullAWSAccess and names what is permitted. AWS warns that if you remove FullAWSAccess without replacing it, all actions from member accounts fail.
Deny lists are simpler to operate and are where most teams begin.
Attaching safely
AWS strongly recommends not attaching an SCP at the root of the organization without testing. Instead:
- Create a test OU and move accounts in one at a time or in small groups.
- Use IAM service last accessed data and CloudTrail to check which services an account really uses.
- Attach the SCP to the test OU and watch for access denied errors.
- Roll out OU by OU.
Also keep a documented path to remove a bad SCP, and make sure someone in the management account can do it quickly.
A common gap
Teams write SCPs, then forget that a permissions boundary and an SCP must both allow an action alongside the identity policy. When a developer reports a denial that no identity policy explains, check the SCP and boundary layers early.
Where Safeguard fits
Safeguard's policies, gates and guardrails work on the software supply chain side, such as blocking a risky dependency at pull request time. SCPs are the equivalent control for cloud account permissions, and they live in AWS.
Quick check
Does an SCP affect the root user of a member account?
Yes. AWS says SCPs restrict permissions for IAM users and roles in member accounts, including the member account's root user, apart from listed exceptions.
Can an SCP protect my management account?
No. SCPs do not affect users or roles in the management account. Secure it with other controls and avoid running workloads in it.
Sources
Last reviewed: 19 October 2026.
