In a multi-account AWS estate, one over-permissioned role or one leaked access key in any member account can undo the security of all the others unless the organisation sets limits that no account administrator can lift. AWS Organizations provides those limits through organisational units (OUs) and three families of organisation policy: service control policies (SCPs) for principals, resource control policies (RCPs) for resources, and declarative policies for service configuration. This guide explains how each one is evaluated, what it cannot restrict, which guardrails to deploy first, and how to roll them out without breaking production. It is written for cloud platform engineers, security architects and the people who own the AWS management account. For account-level controls and IAM design, see the AWS Security Guide and the AWS IAM Policies and Roles Guide.
Key takeaways
- SCPs and RCPs never grant anything. They set a ceiling. Effective permissions are the intersection of SCPs, RCPs and the identity-based and resource-based policies in the account.
- The management account is outside every guardrail. SCPs and RCPs do not apply to it, so it must run no workloads and have very few people with access.
- SCPs cover your principals, RCPs cover your resources. An SCP cannot stop a principal from another organisation using a bucket policy you wrote; an RCP can.
- Declarative policies hold a configuration in place for services such as EC2 (IMDSv2, block public access for AMIs and snapshots), even when AWS adds new APIs, and they also govern service-linked roles.
- Roll out through a Policy Staging OU, measure Access Denied events in CloudTrail, then move up the hierarchy. AWS strongly recommends not attaching untested policies to the organisation root.
How AWS Organizations structures control
An organisation has one management account, a root, and a tree of OUs (up to five levels below the root) that contain member accounts. Policies are attached to the root, an OU or an account and are inherited downwards. New organisations start with a default quota of 10 accounts, which only the management account can ask to raise (up to 50,000). Organisation policies other than consolidated billing need the organisation to have all features enabled.
- Design OUs by function and control set, not by reporting line. AWS multi-account guidance recommends foundational OUs (Security, Infrastructure), a Workloads OU split into production and non-production, a Sandbox OU, and procedural OUs: Policy Staging (test new guardrails), Exceptions, Transitional, and Suspended.
- The account is the security boundary. Separate production from development, and put logging and security tooling in their own accounts so a compromised workload account cannot erase its own evidence.
- Delegate, do not log in to the management account. Services such as IAM Identity Center, GuardDuty, Security Hub and IAM root access management can be administered from a delegated administrator member account, which (unlike the management account) is subject to SCPs.
- Centralise root. With centralised root access enabled, member accounts can have their root password, access keys and MFA removed, new accounts are created without root credentials, and the few root-only tasks (for example deleting a bucket policy that denies all principals) are performed from the management account or the IAM delegated administrator.
The three policy families compared
| Aspect | Service control policy (SCP) | Resource control policy (RCP) | Declarative policy |
|---|---|---|---|
| Controls | Maximum permissions of IAM users and roles in member accounts, including the member root user | Maximum permissions on resources in member accounts, for any principal, including principals outside the organisation | Baseline configuration of a service, enforced at the service control plane |
| Mechanism | API authorisation (Allow and Deny statements) | API authorisation (Deny statements against the default RCPFullAWSAccess) | Configuration attributes, no API actions |
| Service-linked roles | Not affected | Not affected | Governed |
| Management account | Not affected | Not affected | Not affected |
| Default policy | FullAWSAccess on every root, OU and account | RCPFullAWSAccess (cannot be detached) | None |
| Max attached per root, OU or account | 10 | 5 (including RCPFullAWSAccess) | Varies by policy type |
| Max document size | 10,240 characters | 5,120 characters | 10,000 characters |
| Service coverage | All services that use IAM, with a short list of exceptions | A defined list including S3, STS, KMS, SQS, Secrets Manager, CloudWatch Logs, DynamoDB, ECR and Cognito user pools | EC2, VPC and a growing list including backup, tag, S3, GuardDuty and Security Hub policy types |
| Typical use | Deny leaving the organisation, deny unapproved Regions, protect security tooling | Identity perimeter on data stores, HTTPS only, block SSE-C | Require IMDSv2, block public AMI and snapshot sharing, VPC Block Public Access |
Size counts every character. Policies saved in the console have whitespace outside quoted strings stripped; policies sent through the CLI or SDK are stored as written, so minify them in the pipeline.
How SCP evaluation works
- Allow at every level: for an action to be possible, an SCP at the root, at every OU on the path and at the account itself must allow it. Detaching FullAWSAccess from one OU without a replacement Allow denies every action for every account beneath it.
- Deny anywhere wins: a Deny at any level applies to everything below, and no lower-level Allow or IAM policy can override it, including AdministratorAccess on the member root user.
- Deny list or allow list: the default is a deny list (keep FullAWSAccess, add Deny statements). An allow list replaces FullAWSAccess with a list of permitted services, so new AWS services stay blocked until added. AWS warns that relying only on Allow statements and implicit deny can lead to unintended access when broad or overlapping Allows interact; most organisations use deny lists everywhere and an allow list only on tightly regulated OUs.
- Exemptions use conditions: guardrails that must not stop the platform team carry a condition such as
ArnNotLikeonaws:PrincipalARNfor named automation or break-glass roles. Keep that list short, and protect the named roles themselves with a second SCP so nobody else can edit their trust policies. - What SCPs cannot touch: actions by service-linked roles, actions in the management account, principals from outside the organisation, and a few root-only operations (for example registering for Enterprise Support, CloudFront trusted signers, reverse DNS for EC2 and Lightsail email).
Guardrails to deploy first
These are deny-list SCPs, RCPs and declarative policies that suit most organisations. Replace placeholders, test each in the Policy Staging OU, and attach at the lowest OU that needs it before moving higher.
| Guardrail | Policy type and key element | Threat addressed (ATT&CK) | Watch out for |
|---|---|---|---|
| Deny leaving the organisation | SCP Deny organizations:LeaveOrganization | Account removed from all guardrails (T1666 Modify Cloud Resource Hierarchy) | None; attach at root |
| Restrict Regions | SCP Deny with NotAction for global services and StringNotEquals on aws:RequestedRegion | Activity hidden in unused Regions (T1535) | Global services run in us-east-1; exempt KMS and ACM if used with CloudFront; with Control Tower use its own Region deny control |
| Protect security and logging services | SCP Deny on stopping or deleting CloudTrail trails, GuardDuty detectors, Config recorders and Security Hub, except for the platform role | Defence impairment (T1685 Disable or Modify Tools) | Control Tower already ships mandatory controls for its own resources |
| Protect platform roles | SCP Deny iam:DeleteRole, iam:PutRolePolicy, iam:UpdateAssumeRolePolicy on named role ARNs, with admin-role exception | Persistence and guardrail bypass (T1098.001 Additional Cloud Credentials) | Name roles consistently across accounts |
| No long-term IAM users | SCP Deny iam:CreateUser and iam:CreateAccessKey outside an exception OU | Valid cloud accounts (T1078.004) | Legacy integrations that still need keys move to the Exceptions OU |
| Restrict member root user | Centralised root access, plus SCP Deny with aws:PrincipalArn like arn:aws:iam::*:root | Root credential abuse | The AWS example denies only the actions you list |
| Identity perimeter on data | RCP Deny when aws:PrincipalOrgID is not yours and aws:PrincipalIsAWSService is false | Data from cloud storage via cross-account access (T1530) | Third-party accounts and AWS service access need explicit exceptions |
| Block SSE-C on S3 | RCP Deny s3:PutObject when s3:x-amz-server-side-encryption-customer-algorithm is present | Data encrypted for impact (T1486) | Only where applications do not use SSE-C |
| Require IMDSv2 | Declarative policy instance_metadata_defaults, http_tokens = required | Credential theft from instance metadata | Check older AMIs and SDKs first |
| Block public sharing | Declarative policy image_block_public_access = block_new_sharing; snapshot_block_public_access = block_all_sharing | Data exposure through public images and snapshots | block_all_sharing also hides already-public snapshots |
| Control internet paths | Declarative policy vpc_block_public_access with block_ingress or block_bidirectional | Unplanned internet exposure | Allow exclusions only for the egress or ingress VPCs |
The AWS sample repository of RCPs lists three to start with: an identity perimeter (only trusted identities reach your resources), HTTPS-only access, and limiting sts:AssumeRoleWithWebIdentity to trusted OIDC providers and tenants. That last one matters for CI/CD federation; see the Workload Identity Federation Guide.
SCPs versus RCPs: choosing the right tool
- Use an SCP when the question is "what may our own principals do anywhere", for example no unapproved Regions, no IAM users, no disabling GuardDuty. SCPs work for every IAM-integrated service.
- Use an RCP when the question is "who may touch our resources", for example only principals from our organisation may read our S3 buckets, KMS keys or secrets, whatever a bucket policy says. RCPs apply to external principals and to member account root users, but only for the supported services.
- Use both for a data perimeter: an SCP stops your principals using resources outside your organisation (
aws:ResourceOrgID), and an RCP stops outside principals using yours (aws:PrincipalOrgID). Network conditions such asaws:SourceVpccomplete the "expected networks" part. - Use a declarative policy when you want a setting held in place regardless of API or principal, including service-linked roles. Detaching it rolls each attribute back to its previous state, and the account status report shows current values before you enforce.
- Use neither for fine-grained, per-workload least privilege. That belongs in IAM policies and permissions boundaries. Guardrails are coarse by design.
Small and large organisations
- Under about 20 accounts: three OUs (Security, Workloads, Sandbox), five or six root-level deny SCPs, one RCP identity perimeter and the EC2 declarative baseline cover most risk. AWS Control Tower can create and manage this for you.
- Hundreds of accounts: manage policies as code in a dedicated repository, deploy through a pipeline that runs IAM Access Analyzer policy validation, use Policy Staging and Exceptions OUs, and track the 10-SCP and 5-RCP attachment limits by consolidating statements.
- Using AWS Control Tower: Control Tower implements preventive controls with SCPs, RCPs and declarative policies, detective controls with AWS Config rules and proactive controls with CloudFormation hooks. Do not edit the SCPs it owns; add your own alongside, and count them against the attachment limit. See the Cloud Landing Zone Security Guide.
Implementing guardrails safely
- Lock down the management account. No workloads, MFA on root, access only through IAM Identity Center with a small admin group, and a documented break-glass path. See the Break-Glass Account Guide.
- Enable all features, centralised root access and delegated administrators for security services, so day-to-day work happens in member accounts that SCPs constrain.
- Inventory usage. Use IAM last accessed data and CloudTrail to see which services and Regions each OU actually uses, and IAM Access Analyzer external access findings to see which resources are shared outside the organisation before writing an RCP.
- Write policies as code with a short Sid per statement, minified for size, validated in the pipeline, and peer reviewed. Name exempted roles explicitly; never exempt by wildcard on a whole account.
- Test in the Policy Staging OU. Move one representative account at a time, run its deployment pipeline and smoke tests, and filter CloudTrail for
errorCodeAccessDenied with an SCP or RCP explicit-deny message. For declarative policies with Allowed Images Settings, start inaudit_mode. - Promote gradually: Sandbox, then non-production, then production OUs, and only then the root for organisation-wide denies.
- Roll back by detaching the policy from the OU (or moving the account back), which takes effect without changing IAM in the account. Keep the previous policy version in source control so a revert is one pipeline run.
- Quarantine as a pattern: a Suspended or quarantine OU with an SCP that denies all actions except those your incident responders' role needs gives an SCP-backed way to freeze a compromised account quickly. Rehearse it; see the Cloud Incident Response Guide.
Detection and measurement
- Policy changes: alert on Organizations API events in the management account CloudTrail, such as
CreatePolicy,UpdatePolicy,AttachPolicy,DetachPolicy,MoveAccount,DisablePolicyTypeand anyLeaveOrganizationattempt. Send them to the log archive account. See the Cloud Logging and Audit Trail Guide. - Guardrail hits: Access Denied events caused by SCPs or RCPs are useful signals. A spike from one role suggests a broken deployment; denials from an unknown principal for a Region you do not use suggest stolen credentials.
- Drift: compare attached policies to the source repository daily, and use the declarative policy account status report to confirm attribute values.
| Metric | Target or signal |
|---|---|
| Member accounts with root credentials present | Zero after centralised root access |
| Accounts outside an OU with the baseline SCP set | Zero; new accounts land in a governed OU on creation |
| Accounts or roles in the Exceptions OU or on exemption lists | Falling over time, each with an owner and expiry |
| Organisation policy changes made outside the pipeline | Zero |
| Mean time to move a compromised account into quarantine | Minutes, measured in exercises |
| Resources with external access findings not covered by an RCP exception | Zero |
Common failure patterns
- Workloads in the management account. Because no SCP or RCP applies there, any role in it is effectively unconstrained. Move workloads out and treat its credentials as the most sensitive in the estate.
- Guardrails that never covered the attacker's path. In the Amazon AWS Crypto-Mining Campaign 2025, compromised admin-like credentials created IAM users with access keys, a Lambda function URL with no authentication and hundreds of auto-scaled instances. AWS's own recommendations included SCPs denying Lambda function URLs with
authTypeNONE and blocking IAM user creation where it is not needed (T1496.001 Compute Hijacking). - Abuse of legitimate features. In the Codefinger S3 Ransomware 2025 campaign, stolen keys used SSE-C to encrypt buckets with attacker-held keys. AWS subsequently published an RCP pattern that denies SSE-C uploads organisation-wide for organisations that do not use it.
- Over-broad exemptions. Exempting
arn:aws:iam::*:role/*Admin*from every deny means any principal that can create a role with that name walks past the guardrail. Exempt exact role names and protect them. - Untested root attachments. A Region-deny SCP attached at the root without exempting global services can stop IAM, Organizations or Route 53 changes everywhere. Use Policy Staging first.
- Believing SCPs stop outsiders. A permissive bucket or KMS key policy granting another account is untouched by SCPs. Only an RCP or the resource policy itself closes it.
Framework mapping
| Framework | Reference | How organisation policies support it |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05, PR.PS-01, GV.PO-01 | Enforced least-privilege ceilings, configuration baselines, policy enforced technically |
| NIST SP 800-53 Rev. 5 | AC-3, AC-6, CM-2, CM-6, CM-7, AU-9 | Access enforcement, least privilege, baseline and least functionality (Region and service limits), protection of audit tooling |
| CIS Controls v8.1 | Control 4 (Secure Configuration), Control 6 (Access Control Management) | Org-wide secure defaults and limits on account and credential creation |
| ISO/IEC 27001:2022 Annex A | A.5.23, A.8.2, A.8.9 | Security for use of cloud services, privileged access rights, configuration management |
| MITRE ATT&CK | T1078.004, T1535, T1666, T1685, T1486, T1496.001 | Threats the guardrails in this guide constrain |
Where identity fits
Most guardrails in this guide are really about non-human identities: CI/CD roles, automation roles, access keys and federated workload tokens. SCPs that forbid IAM users and access keys push workloads towards short-lived role credentials, and RCPs that limit sts:AssumeRoleWithWebIdentity to trusted OIDC tenants protect federation trust. The exempted platform roles are the most privileged identities in the estate, so review them in the same cycle as the policies. See the Cloud Workload Identity Guide and the Cloud PAM and CIEM Guide.
Practitioner checklist
- Confirm the management account runs no workloads and that access to it is limited, MFA-protected and logged.
- Enable all features, centralised root access and delegated administrators for security services.
- Build OUs by function, including Policy Staging, Exceptions and Suspended OUs, and set the default landing OU for new accounts.
- Attach baseline SCPs: deny LeaveOrganization, Region restriction, protection of logging and security services and platform roles, and no IAM users or access keys outside exceptions.
- Deploy an RCP identity perimeter on supported data services, plus SSE-C and HTTPS-only RCPs where they fit.
- Apply EC2 declarative policies for IMDSv2, public AMI and snapshot sharing, and VPC Block Public Access.
- Keep all organisation policies in source control, validated and deployed by pipeline, within the size and attachment quotas.
- Alert on Organizations policy and account-move events and on guardrail Access Denied patterns.
- Rehearse moving a compromised account into the quarantine OU and rolling back a faulty policy.
- Review exemption lists and Exceptions OU membership every quarter, with an owner and expiry for each.
Standards and references
- AWS: Service control policies (SCPs)
- AWS: Resource control policies (RCPs)
- AWS: Declarative policies
- AWS: SCP evaluation
- AWS: Quotas and service limits for AWS Organizations
- AWS: Control Tower control behaviour
- AWS Security Blog: Preventing unintended encryption of Amazon S3 objects
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: AWS Security Guide · Cloud Security Guide · CNAPP Guide · Azure Policy and Management Groups Guide · Google Cloud Organization Policy Guide