AWS SCP FullAWSAccess: What Actually Happens Without Account Attachment

AWS Service Control Policies are one of the most powerful governance controls available in AWS Organizations. They operate above the IAM layer - they are guardrails that constrain what IAM policies in member accounts can allow. Done correctly, SCPs enforce organisation-wide policy that no individual account administrator can override. Done incorrectly, they create a false sense of security that leaves accounts completely ungoverned.

The most common form of that false sense of security involves a single policy: FullAWSAccess. It is visible in every AWS Organization. Many engineers assume that because it is there, it is doing something. This article explains precisely when it is and is not in effect - and what the gap costs you.

What Is FullAWSAccess?

FullAWSAccess is an AWS-managed Service Control Policy that is automatically created in every AWS Organization when you first enable the SCP policy type. Its policy document is exactly what the name suggests:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

It allows everything. When you first enable SCPs, AWS attaches FullAWSAccess to the root and all existing OUs automatically. This is the default state. It means that, at the organisation level, no actions are blocked - SCPs are in place, but they permit everything. From this starting point, you layer in restrictive deny-list SCPs to enforce your governance boundaries.

This is a critical design principle of AWS SCPs: they do not grant permissions - they restrict what IAM policies can allow. SCPs define the maximum permission boundary for an account. An IAM policy can only do what both the IAM policy and the applicable SCPs allow. If no SCP is attached, there is no organisation-layer restriction at all.

The Core Misunderstanding: Existence vs. Attachment

This is the article's central point. Many engineers inspect their AWS Organization - either via the console under AWS Organizations → Policies → Service control policies, or via the CLI command aws organizations list-policies --filter SERVICE_CONTROL_POLICY - and see FullAWSAccess in the list. They conclude: SCPs are configured, governance is in place.

That conclusion is wrong. An SCP only has effect when it is attached to a target - a root, an OU, or an individual account. The existence of a policy in the organisation's policy library does nothing on its own. It is a document sitting in a vault. The vault being in the building does not mean the doors are locked.

In practice, this situation arises more often than it should. An administrator detaches FullAWSAccess from an account or OU while preparing to replace it with a more restrictive policy, then never completes the attachment. A migration exercise moves accounts between OUs and breaks inherited attachments. An automated provisioning script creates accounts without attaching any SCP. In each case, the result is the same: an account with no SCP attached.

The implications are immediate. Any IAM policy in an account with no SCP attached can allow any AWS action - including actions you may have assumed were blocked by a deny-list SCP at the root or OU level. Those deny-list SCPs only restrict the accounts and OUs they are attached to. An account outside that attachment hierarchy is outside their scope entirely.

The Governance Risk: Silent Blast Radius

An account with no SCP attached is effectively ungoverned from an organisation-level perspective. There is no maximum permission boundary. IAM policies in that account can allow full administrative access across every AWS service with no organisation-layer control in the path.

Consider the failure mode in practice. A developer working in what they believe is a sandboxed account attaches the AWS-managed AdministratorAccess policy to a role to unblock a deployment. Under normal governance, a deny-list SCP at the OU level would limit what that role can do even with AdministratorAccess - blocking actions like disabling CloudTrail, accessing restricted regions, or interacting with production data stores. With no SCP attached, there is no guardrail. The AdministratorAccess policy means exactly what it says.

In a payment infrastructure context, the services at risk in an ungoverned account are exactly the ones that handle the most sensitive operations:

• DynamoDB - payment transaction records and idempotency state
• Secrets Manager - processor API keys and credentials
• KMS - encryption keys protecting cardholder data
• Lambda - payment processing logic and authorisation handlers
• CloudTrail - the audit trail itself, which can be disabled

The risk is compounded by the fact that this gap is often invisible until audit time. No alarm fires when an SCP is detached. No AWS Config managed rule checks for accounts with zero SCP attachments by default. The organisation looks governed in the console because FullAWSAccess is still listed under policies. The gap only surfaces when you enumerate what is actually attached.

How to Detect It

Detecting ungoverned accounts requires explicitly querying SCP attachments per target - not just listing policies. The following CLI commands cover the full audit:

# List all SCPs in the organization (existence only - does not confirm attachment)
aws organizations list-policies --filter SERVICE_CONTROL_POLICY

# Check what SCPs are attached to a specific account
aws organizations list-policies-for-target \
  --target-id 123456789012 \
  --filter SERVICE_CONTROL_POLICY

# Check what SCPs are attached to a specific OU
aws organizations list-policies-for-target \
  --target-id ou-xxxx-xxxxxxxx \
  --filter SERVICE_CONTROL_POLICY

# List all accounts in the organization to iterate over
aws organizations list-accounts

If the list-policies-for-target commands return an empty Policies array for a given account or OU, that target has no SCP directly attached to it. You also need to verify the inheritance chain - an account inherits SCPs from its parent OU and the root. If neither the account nor any parent has an SCP attached, the account is ungoverned.

For a complete audit across a large organization, you can script this by calling list-accounts and iterating list-policies-for-target and list-parents for each account to walk the OU hierarchy. The effective SCP set for an account is the intersection of all policies attached at every level from the account up to the root.

# Walk the parent hierarchy for an account to check inherited SCPs
aws organizations list-parents --child-id 123456789012

# Then check each parent OU for its attached SCPs
aws organizations list-policies-for-target \
  --target-id ou-xxxx-xxxxxxxx \
  --filter SERVICE_CONTROL_POLICY

# An account is ungoverned only if no SCP exists at the account,
# any parent OU, or the root level.

The Correct Governance Pattern

A well-governed AWS Organization uses SCPs in layers, with each level of the hierarchy enforcing the appropriate scope of controls. The pattern that works for production environments is:

Root Level

Attach a restrictive deny-list SCP to the root that applies universally across every account in the organisation, regardless of OU structure. This is where you enforce non-negotiable controls:

• Block all AWS regions except approved regions
• Deny root account usage (except for specific break-glass scenarios)
• Deny disabling CloudTrail or AWS Config
• Deny leaving the AWS Organization
• Deny creating or modifying AWS account contacts without approval

OU Level

Attach FullAWSAccess to each OU as the base allow policy, then layer in environment-specific deny policies on top. The deny policies vary by environment:

• Production OU: Deny deployment actions without approval, restrict direct console access, enforce MFA for sensitive API calls
• Development OU: Restrict access to production data stores and KMS keys, block actions that could impact billing above a threshold
• Sandbox OU: Restrict to approved services only, block VPC peering to production networks, enforce hard cost caps via budget actions

Account Level

Account-level SCP attachments should be used sparingly, for exceptions only. The majority of governance should be inherited from the OU hierarchy. If you find yourself attaching unique SCPs to individual accounts, it is usually a signal that the OU structure needs refinement.

Remediation Steps

If you have identified accounts or OUs with no SCP attachment, remediation is straightforward but must be done carefully to avoid inadvertently restricting accounts that depend on the current (ungoverned) state.

1. Enumerate all targets. Run list-policies-for-target for every account and OU in the organisation. Build a complete map of what is attached where, including inherited policies via list-parents. Do not proceed without this inventory.

2. Identify accounts with zero effective SCPs. An account has zero effective SCPs only if there is no SCP attached at the account level, any parent OU, or the root. Accounts that inherit from a well-governed OU hierarchy may not need direct intervention.

3. Attach FullAWSAccess as immediate remediation. For accounts with no effective SCP, attach FullAWSAccess directly to the account or its OU. This restores parity with AWS's default state and does not restrict any existing permissions - it simply ensures SCPs are active. Run aws organizations attach-policy with the FullAWSAccess policy ID.

4. Layer in environment-specific deny policies. Once FullAWSAccess is attached and you have a stable governance baseline, progressively apply deny-list SCPs per OU. Start with the non-negotiable controls (region restriction, CloudTrail protection) and work towards environment-specific policies over a controlled change window.

5. Automate ongoing detection. Add an AWS Config rule or an EventBridge rule to alert on SCP detachment events. The EventBridge event source is aws.organizations with event name DetachPolicy. Route alerts to your security team for review within a defined SLA. Consider an automated Lambda that re-attaches a baseline policy on detachment events for production OUs.

Implication for Payment Infrastructure

Regulated environments - PCI-DSS, SOC 2 Type II, ISO 27001 - share a common requirement: you must be able to demonstrate that access controls are consistently enforced across every environment in scope. Not most environments. Every environment.

An SCP gap breaks that help. If one account in your payment infrastructure OU has no effective SCP, you cannot make a consistent assertion about the maximum permission boundary in your cardholder data environment. Assessors will ask: how do you know no account can exceed the permissions defined in your security baseline? If the answer depends on correct SCP attachment - which it does - then you need an auditable, automated mechanism to enforce and monitor that attachment.

The specific risks in a payment infrastructure context are not abstract. An ungoverned account in a production or staging OU could allow:

• Direct access to KMS keys used to encrypt cardholder data, bypassing the key policy controls you rely on for separation of duties
• Modification of Secrets Manager secrets storing processor credentials, without the change management controls your governance SCPs would otherwise enforce
• Disabling of CloudTrail in the account, eliminating the audit trail that underpins your PCI-DSS Req 10 compliance posture
• Cross-account role assumptions that your governance model assumes are blocked by region-restriction SCPs - which do not apply to an ungoverned account

This is not a theoretical risk. SCP configuration gaps appear regularly in cloud security assessments, and they are consistently one of the findings that assessors weight most heavily because they represent a systemic failure of the governance layer rather than a misconfiguration of a single resource.