AWS Organizations & SCPs

Understand the AWS account hierarchy and organization-level permission guardrails that influence enterprise access.

AWS Organizations allows enterprises to arrange accounts into a hierarchy and apply Service Control Policies as permission guardrails. Securitain provides organization context so IAM security is not interpreted as though every AWS account operates independently.

Where to find Organizations & SCPs

The current view contains:

• OU Hierarchy
• Service Control Policies

Current summary cards include: Org Units, Service Control Policies and Customer SCPs.

Why Organizations matters

A large AWS estate often looks like:

AWS Organization
      ↓
Root
      ├── Production OU
      │     ├── App Account
      │     └── Data Account
      │
      ├── Development OU
      │     └── Dev Accounts
      │
      └── Security OU
            └── Security Account

Organizational Units

An Organizational Unit groups AWS accounts within AWS Organizations. OUs are commonly used for environment separation, business units, security boundaries, regulatory zones and workload types. The current Securitain OU Hierarchy view shows the structure collected from AWS Organizations.

OU Hierarchy

The current view can display:

• OU name and OU ID
• child OUs
• directly represented accounts
• directly represented SCP count

Use it to answer: which accounts belong to this OU, how is the AWS organization structured, and which OUs have SCP attachments represented?

Service Control Policies

An SCP defines the maximum permission boundary available to IAM principals in affected AWS member accounts.

IAM Policy allows action
        ∩
SCP allows action
        ↓
Action may remain available

SCPs are guardrails

IAM Policy
"What the identity is granted"

SCP
"What the organization permits accounts to use"

Policy targets

An SCP can be attached to supported AWS Organizations targets including root, OU and account. The current Securitain SCP view can show attached targets returned by AWS, making it easier to understand where a policy is deliberately applied.

AWS-managed vs customer SCPs

The current product distinguishes AWS-managed and customer-created SCP context. This helps separate default or system-managed policy context from enterprise-specific guardrails. The summary can include total Service Control Policies and customer SCP count.

Policy documents

The current Securitain view can display the SCP policy document where available. Use this to inspect allowed/denied action scope, resource scope, conditions and policy structure. Policy interpretation requires AWS Organizations semantics.

Example: deny region usage

Developer Role
   ↓
Identity policy allows service action
   ↓
Organization SCP blocks disallowed region
   ↓
Request denied

This illustrates why an attached IAM allow is not always effective access.

Example: protect security services

An organization can use SCPs as guardrails around security-sensitive actions — for example, constraining member accounts from disabling particular organization-required controls. The correct policy depends on the enterprise architecture.

Direct attachment vs inherited effect

The Organizations view primarily shows:

• hierarchy
• collected SCPs
• directly represented targets and attachments

Organizations & SCPs vs Effective Permissions

The two views complement each other.

Organizations & SCPs vs Multi-Account Securitain

Collection context

AWS Organizations information requires supported Organizations read permissions. In many environments, organization-wide information is available only from appropriate AWS account roles or contexts.

Investigating an SCP

1. 1

   Identify the policy

   Review its name and purpose.

2. 2

   Review policy document

   Understand the guardrail — allowed/denied scope, resources and conditions.

3. 3

   Review targets

   Determine whether it applies to root, OU or account.

4. 4

   Review OU hierarchy

   Understand which accounts may be in the affected structure.

5. 5

   Compare with IAM permission

   Use Effective Permissions when investigating the effect on an identity.

6. 6

   Confirm ownership

   Identify the platform or security team responsible for the organization policy.

Evidence and limitations

Organizations/SCP results depend on:

• AWS Organizations usage and read permissions
• account context and collected OUs
• collected policies and direct targets
• scan freshness

Related guides