An AWS Service Control Policy (SCP) sets the maximum permissions available to IAM users and roles in member accounts. It does not grant permission. An action still needs IAM or resource-based permission and must remain allowed by the effective SCP boundary from the organization root to the account.
How SCPs work
SCPs are organisation-wide permission guardrails. You attach them to an AWS Organization root, an organizational unit (OU), or an individual member account. Policies inherited from parent containers combine with policies attached directly to the account.
An action succeeds only when all of these layers allow it:
- The combined SCPs at every level from the organization root through each OU to the account permit the action.
- The principal’s identity policy or a resource policy grants the action.
- No other control, such as a permissions boundary or session policy, denies it.
For allow-list SCPs, an explicit Allow must exist at every level in that path. Multiple SCPs attached at one level combine. An explicit Deny anywhere in the path overrides an Allow elsewhere. An SCP never creates permission by itself.
What SCPs affect
SCPs apply to IAM users and roles in member accounts, including the member account root user. They do not restrict identities in the AWS Organizations management account or permissions attached to service-linked roles.
Before using SCPs, enable all features in AWS Organizations. SCPs are unavailable in consolidated-billing-only mode.
SCPs are a good fit for controls that should hold across many accounts, such as:
- keeping workloads in approved AWS Regions;
- preventing security services from being disabled;
- blocking public S3 access configurations;
- restricting which services a sandbox OU can use.
They are not a replacement for least-privilege IAM policies, resource policies, or continuous posture monitoring.
SCP example: deny leaving approved Regions
The following policy denies most actions outside eu-central-1 and eu-west-1. Global services need careful exceptions, so adapt the NotAction list to your environment before deployment.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyOutsideApprovedRegions",
"Effect": "Deny",
"NotAction": [
"account:*",
"billing:*",
"cloudfront:*",
"iam:*",
"organizations:*",
"route53:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-central-1",
"eu-west-1"
]
}
}
}
]
}Region-deny policies are deceptively easy to get wrong. AWS can add services, global endpoints do not all behave alike, and existing automation may call an endpoint you did not expect. Start with AWS’s maintained example, review every exception, and test it in a non-production OU.
SCP example: protect AWS CloudTrail
This guardrail prevents member-account principals from stopping logging or deleting trails:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ProtectCloudTrail",
"Effect": "Deny",
"Action": [
"cloudtrail:DeleteTrail",
"cloudtrail:StopLogging"
],
"Resource": "*"
}
]
}If a central security role needs a controlled exception, add a condition that excludes that role’s principal ARN. Test the assumed-role ARN format rather than copying an IAM role ARN blindly.
Create and attach an SCP
- Sign in to the AWS Organizations console by assuming an authorized IAM role in the organization’s management account. Do not use the root user for routine administration.
- Open AWS Organizations → Policies → Service control policies.
- Enable SCPs if they are not already enabled.
- Choose Create policy, add a clear name and description, then enter the JSON policy.
- Save the policy and attach it first to a test OU containing non-production accounts.
- Validate expected workloads and administrative recovery paths before moving the policy higher in the organization.
Avoid attaching an untested deny policy directly to the organization root. A syntax-valid policy can still break deployments, incident response, or account administration.
Safe rollout checklist
- Inventory current service and Region usage before writing the policy.
- Keep a test OU and representative test account.
- Start with a narrow control and widen it only after observing the effect.
- Preserve a documented recovery path through the management account.
- Monitor CloudTrail for denied actions during rollout.
- Review SCPs when AWS adds services or your account structure changes.
- Keep IAM permissions least-privileged; an SCP is only the outer boundary.
SCPs and cloud security posture management
SCPs prevent selected actions, but they do not tell you whether every account is configured securely today. A CSPM such as Kloudle continuously checks the posture inside those boundaries—for example, exposed resources, risky IAM configurations, missing encryption, and drift across AWS accounts.
Use SCPs for preventive guardrails and CSPM for continuous visibility and verification. The two controls solve different parts of the same governance problem.
