AWS Service Control Policies (SCPs): A Complete Guide for 2026

The cloud is all about innovation at a speed never before possible. This can often lead to rapid development sprints and a proliferation of identities and infrastructure, and with that, excessive privilege. In large scale enterprises, IAM governance can be difficult. To accommodate this, Amazon Web Services (AWS) created Service Control Policies. The following guide will:

• Define what a Service Control Policy (SCP) is.
• Define its functionality in a larger governance strategy.
• Cover the September 2025 update that gave SCPs full IAM policy language support.
• Explain how the new Resource Control Policies (RCPs) fit alongside SCPs.
• Detail challenges associated with implementing them.

Understanding Service Control Policies in AWS

A service control policy is a set of controls at the organizational unit that restricts the maximum level of permissions that users, roles, and even root users in AWS accounts can hold. They act as guardrails, trumping all other levels of policy to ensure security standards are consistently applied across the organization.

SCPs are particularly important in large-scale enterprises where managing and enforcing consistent policies across numerous accounts is a complex task. This centralized governance model is essential for maintaining a balance between enabling access and enforcing security and compliance across the AWS environment.

SCP benefits include:

• Accommodate enterprise-grade scale and multi account environments.
• Centralized control over privilege governance.
• Help meet regulatory or corporate requirements.
• Help build custom environments tailored to specific data security or access management needs.
• Inheritance of policy from OU down the hierarchy to accounts means less manual effort.
• More development freedom to manage their own permissions because you’ve set guardrails for them.

Components of Service Control Policy

Understanding the components of an SCP is the first step before writing them:

Statement: The core of the policy, defining permissions or restrictions.

Statement ID (Sid): A unique identifier for each statement, aiding in policy management and troubleshooting (e.g. DenyAllOutsideEU).

Effect: Determines whether the policy results in an ‘allow’ or ‘deny’ statement.

Action: Specifies the actions the policy allows or denies (e.g. s3:* for all Amazon S3 actions). As of September 2025, wildcards can now appear at the beginning, middle, or end of the Action string, giving you much more flexibility when targeting groups of API calls.

NotAction: Specifies what is not covered by the policy, useful for broad permissions with specific exceptions. As of September 2025, NotAction now works in Allow statements as well as Deny statements.

Resource: Defines the AWS resources to which the policy applies, using ARNs (Amazon Resource Names). Historically SCPs only supported “*” here, but as of September 2025 you can target individual resource ARNs directly in your SCPs.

NotResource: The inverse of Resource. Lets you say “this policy applies to everything except these ARNs.” Handy when you want a broad restriction but need to carve out a small set of exceptions (e.g. deny modifications to all S3 buckets except a specific logging bucket). This was added in the September 2025 update.

Condition: Additional criteria that refine the policy’s application, such as date, time, or user attributes (e.g. aws:SourceIp). As of September 2025, conditions can be used in both Allow and Deny statements, not just Deny.

How Do AWS Service Control Policies Work?

SCPs are part of the AWS Identity and Access Management (IAM) framework, but serve a distinct purpose. Unlike IAM policies that grant permissions, SCPs are used to define limits and restrictions. They do not grant permissions but instead act as a filter over the permissions that can be exercised within an AWS account.

SCPs are applied at the AWS Organization or Organizational Unit (OU) level, affecting all accounts within that scope.

SCP Allow: Sets the boundaries for what actions IAM policies can permit but does not grant permissions itself. For ‘allow’ to work, there must be a statement made at every level from root through each OU to the account you want affected. An SCP is deny-by-default otherwise.

SCP Deny: When an SCP includes a ‘deny’ statement, it explicitly prohibits certain actions, regardless of any other permissions that might be granted elsewhere. In the example below you can see a ‘deny’ statement at the OU level disrupting the ‘allow’ statement at the account level.

 AWS SCP evaluation strategy docs

AWS SCP vs IAM Policy vs RCP: What Are the Key Differences?

Short answer: SCPs and RCPs both apply at the AWS Organization or OU level and act as guardrails, while IAM policies grant permissions to individual users, groups, or roles inside an account. SCPs govern what principals (users and roles) can do. RCPs govern what resources can be accessed and by whom. IAM policies are the only one of the three that actually grants permissions.

With three policy types in the picture as of late 2024, here’s how they stack up:

	SCP (Service Control Policy)	IAM Policy	RCP (Resource Control Policy)
Scope	Organization or OU level	User, group, or role inside a single account	Organization or OU level
What it controls	Maximum permissions for principals (users, roles, root) across accounts	Grants permissions to identities or resources inside an account	Maximum permissions for resources across accounts (e.g. who can access an S3 bucket, KMS key, or SQS queue)
Grants permissions?	No, only restricts	Yes	No, only restricts
Launched	2017 (full IAM language added Sept 2025)	2011	November 2024

RCPs are a sibling policy type to SCPs, introduced by AWS in November 2024. They cover resource-side governance use cases that SCPs cannot fully handle, particularly for services like S3, STS, KMS, Secrets Manager, and SQS. For example, an RCP can enforce that an S3 bucket may only be accessed by principals from within your organization, regardless of how the bucket’s own resource policy is configured. SCPs cannot enforce that boundary on the resource itself because they only act on principals.

If you’re designing org-wide guardrails in 2026, it’s worth understanding both. SCPs handle the “who can do what” question. RCPs handle the “who can touch this resource” question. Used together, they close gaps that neither could close alone.

Setting Up a Service Control Policy

Before actually implementing an SCP in AWS, your team will likely follow a process similar to the following: 1) Pitching the use case for one, 2) Requesting usage, 3) Security Team or equivalent team analysis of the SCP use case, 4) Map possible usage scenarios and necessary testing. Finally, you’ll be ready to actually execute building one out.

To set up SCPs in AWS, follow these steps:

1. Create an AWS Organization: Establish your AWS Organization for centralized management.
2. Enable Service Control Policies: Activate SCPs within your organization settings.
3. Create an AWS SCP: Define your SCP, specifying the allowed or denied actions and resources.
4. Choose Your Statement: Decide between ‘Allow’ and ‘Deny’ statements based on your requirements.
5. Add Conditions (Optional): Specify conditions for more granular control.

AWS resource tagging strategy blog

5 AWS SCP Best Practices and Tips

• Use the management account judiciously: Reserve the management account for administrative tasks only and apply SCPs primarily at the OU level.
• Test your SCPs before application: Implement SCPs in a controlled environment before rolling them out organization-wide to avoid disrupting or breaking other processes.
• Give your policy a recognizable name and description: Something like DenyChangestoS3 is easier to manage than a generic ID six months later.
• Use the new IAM language elements carefully: The September 2025 update gave SCPs a lot more expressive power, but with that comes complexity. A policy mixing NotAction, NotResource, and conditional Allow logic can be precise and deeply confusing to read. Document the intent in plain English alongside the JSON.
• Keep a break-glass IAM role in the management account: SCPs apply to every account in your org except the management account itself, which means a misconfigured SCP can lock your team out of member accounts. A pre-provisioned, tightly scoped break-glass role in the management account (with strong MFA and alerting on use) gives you a way to recover without an AWS support ticket.

AWS SCP Examples

Sensitive data protection.

Here’s an example of an SCP used for sensitive data protection. It denies users from deleting S3 buckets or objects:

Same idea, using the September 2025 syntax: If you want to protect every S3 bucket from deletion except a known sandbox bucket, the new NotResource element makes this much cleaner than chaining multiple statements:

2. Denying root user actions

This example enforces what used to be a foundational security best practice: denying any usage from the root user.

Heads up on root user controls: AWS now offers centralized root access management inside AWS Organizations, and as of June 17, 2025, root MFA enforcement is mandatory for member accounts. That means the primary control for root user risk is now centrally managed at the org level, not a deny-root SCP. This SCP is still valuable as a defense-in-depth layer, but it shouldn’t be your only control.

3. Region restriction

Restricting which AWS regions your org can operate in is one of the most common SCP use cases in production, especially for data residency and compliance. This SCP denies any action outside us-east-1 and us-west-2, with an exception for IAM and a few other global services that don’t operate on a regional basis:

Service Control Policy Use Cases

As we know, SCPs are used to enforce organizational guardrails and uphold security. Some more specific use cases for them include:

Data security and protection: To protect data, you can use an AWS SCP to ensure only specified identities are accessing specific data, or enforce that no members can change configurations on data services like S3.

Denying changes to security services: AWS offers security monitoring and detection services that help keep an eye on your environment and alert to threats. You can use guardrails to ensure no accounts can alter these services and disrupt protection.

Privileged access controls: If your organization has certain privilege or access standards you want maintained across the org, you can use an SCP to limit maximum permissions. Pairing this with just-in-time access for the rare cases users do need elevated rights keeps the standing privilege footprint small.

Regional controls: In multi-account environments, you can inhibit usage within certain regions.

AWS SCPs: Addressing the Challenge

Visibility

The complexity of managing multiple overlapping policies, including SCPs and IAM policies, can lead to a lack of visibility and control. It’s essential to have a clear understanding of the cumulative effect of these policies on your AWS environment, otherwise potential issues arise:

The September 2025 update making SCPs more expressive is a double-edged sword here. More flexibility means more ways for a policy to do something subtle, and a policy combining NotAction, NotResource, and conditional Allow logic can be very hard for a human to read at a glance. Visibility tooling that computes effective permissions matters more in 2026 than it did when SCPs were simpler.

Without proper visibility your identities can end up with access you never authorized. As we know, privilege can easily be inherited in the cloud, making it harder to see ‘on paper.’ This type of unseen privilege can result in opportunities for lateral movement. That lateral movement can be exploited by malicious attackers.

On the contrary, implementing too conservative of a strategy with hefty denial via Service Control Policies, you end up with development interruption and inefficient request processes.

Responsibility

Cloud security generally faces a confusing distribution of responsibility because it is a new frontier. There is discrepancy between who builds the cloud (and consequentially influences the security of it) and who manages security and IAM. Defining who owns Service Control Policies is up to the discretion of an enterprise (e.g. DevOps vs. Security teams vs. Governance teams) but this lack of definition can lead to gaps, confusion, and not using the feature to its full potential.

The answer is a solution with both the technology to compute effective permissions, the logical intersection of how all these IAM policies and SCPs interact with each other, and operationalized workflows for building and remediating.

Protect Sensitive Permissions With Sonrai

Frustrated working with SCPs? Don’t know where to start, but know you want to set up org-wide guardrails? Sonrai’s cloud permissions firewall platform works top-down to enforce least privilege at the org level. Anything your identities don’t need is restricted from use, with exceptions made to those who do need it. New access is granted on the fly with a just-in-time access workflow integrated into your ChatOps tool.

FAQ

1. How do AWS Service Control Policies (SCP) impact the cost and efficiency of AWS resource utilization in an organization?

AWS Service Control Policies (SCP) can significantly influence both the cost and efficiency of AWS resource utilization within an organization. By enabling administrators to set permissions that limit the actions users and roles can perform, SCPs help prevent unauthorized access or inadvertent expenses by restricting resource deployment in unauthorized regions or the use of high-cost services.

2. Can AWS SCPs be integrated with third-party security and compliance monitoring tools, and if so, how?

While AWS SCPs are designed to work within the AWS environment, integrating them with third-party security and compliance monitoring tools is possible through the use of AWS APIs and other intermediary software solutions that bridge AWS configurations with external systems. This integration allows for enhanced monitoring, reporting, and compliance management across both AWS and non-AWS resources.

3. What are the specific challenges or limitations when migrating existing IAM policies to SCPs within large, complex AWS environments?

Migrating existing IAM policies to SCPs in large, complex AWS environments presents specific challenges, including the need to comprehensively understand the existing permissions landscape, ensuring that SCPs do not inadvertently block critical business operations, and managing the hierarchical nature of SCPs to effectively apply the principle of least privilege. This process requires careful planning, testing, and gradual implementation to avoid disruption.

4. How are AWS Resource Control Policies (RCPs) different from Service Control Policies (SCPs)?

SCPs and RCPs are both org-level guardrails, but they govern different things. SCPs set the maximum permissions for principals, meaning users, roles, and root users across the accounts in your organization. RCPs set the maximum permissions on the resource side, meaning who can access a given resource (like an S3 bucket, KMS key, or SQS queue) regardless of what that resource’s own policy allows. Neither grants permissions on its own. In practice you use SCPs to control what your identities can do, and RCPs to control how your resources can be accessed. RCPs launched in November 2024 and currently support a defined set of services including S3, STS, KMS, Secrets Manager, and SQS.

5. Do I still need an SCP that denies root user actions if AWS now offers centralized root access management?

The center of gravity for root user control has shifted. As of June 17, 2025, AWS enforces root MFA on all member accounts in an Organization, and centralized root access management lets you remove long-lived root credentials from member accounts entirely. That is now the primary control. A deny-root SCP still has value as defense in depth, especially for catching any action attempted by a principal whose ARN matches :root even after centralized management is in place. So you don’t necessarily need it the way you used to, but keeping it as a backstop is reasonable.