Compliance Frameworks
BETA// Beta Mapping Disclaimer
Framework mappings are currently in beta. These references are generated based on technical specifications and common industry alignments. Mappings may be incomplete or inaccurate; always consult with a qualified auditor for official compliance validation.
Overview
Use Resource Control Policies from the Management account to enforce centralized maximum-permission guardrails on resources across the organization, closing the gap that SCPs cannot address. RCPs complement SCPs in the policy evaluation chain: SCPs constrain what identities can do, RCPs constrain what resources can accept. Together they form the data perimeter of the landing zone. Recommended foundational RCPs for a landing zone:
- Deny access to S3 buckets from principals outside the organization (prevents cross-account exfiltration via bucket policy)
- Deny access to SQS queues from principals outside the organization
- Deny access to Secrets Manager secrets from principals outside the organization
- Deny sts:AssumeRole on roles from principals outside the organization unless the role trust policy explicitly allows it
- Restrict S3 access to known VPC endpoints only for sensitive OUs
- Deny ECR image pulls from outside the organization
- Deny OpenSearch Serverless collection access from outside the organization
SCPs restrict what IAM identities in member accounts can do - but they cannot prevent an external principal from accessing a resource if that resource's own policy grants them access. A member account operator who adds an external account to an S3 bucket policy bypasses all SCP-based controls entirely. RCPs close this gap: they sit on the resource side of the policy evaluation and cap the maximum permissions any resource policy can grant, regardless of what the resource policy says. The effective permission on a resource is the intersection of the RCP, the identity's SCP, the IAM identity policy, and the resource-based policy - all four must allow the action. RCPs are supported on S3, SQS, STS, Secrets Manager, ECR, OpenSearch Serverless, ... They are managed from the Management account and attached at the organization root or OU level. Unlike SCPs, RCPs do apply to the Management account. The primary use case is building a data perimeter: ensuring that only trusted identities (organization principals), from trusted networks (known VPCEs), can access sensitive resources - regardless of what individual resource policies say.
SCPs alone are insufficient to prevent data exfiltration. An operator in a member account with sufficient IAM permissions can attach a permissive S3 bucket policy that grants an external attacker-controlled account direct resource access. The SCP cannot see or block this because the access request comes from the external account, which is outside the organization's SCP boundary entirely. RCPs enforce the organization boundary on the resource itself, meaning even a deliberately misconfigured resource policy cannot grant access beyond the RCP limit.
Remediation Strategy
Enable the RCP policy type on the organization root. Draft each RCP from the list in the description as a separate named policy. Test in a sandbox OU against real workloads before attaching to production OUs or root. Audit all existing cross-account resource policies using IAM Access Analyzer before enforcement.
Run an organization-wide Access Analyzer scan (AWS-IAM-010) to inventory all existing cross-account resource policies before drafting RCPs.
Enable the RESOURCE_CONTROL_POLICY type on the organization root.
Create each RCP as a separate named policy in the Management account.
Attach each RCP to a sandbox OU and verify legitimate workloads are not blocked.
Promote to the target OU or organization root after validation.
Review RCP coverage quarterly as new supported services are added by AWS.
Enforcement Logic
Verify that the RCP policy type is enabled on the organization root and that at least one non-AWS-managed RCP is attached to the root or a target OU. An organization with no custom RCPs has no resource-side data perimeter guardrails. Also check per-OU attachment to confirm coverage extends beyond the root.
ROOT_ID=$(aws organizations list-roots \
--query "Roots[0].Id" --output text)
# Verify RCP policy type is enabled on the root
aws organizations list-roots \
--query "Roots[0].PolicyTypes[?Type=='RESOURCE_CONTROL_POLICY'].Status" \
--output text
# Count custom (non-AWS-managed) RCPs attached to root
aws organizations list-policies-for-target \
--target-id "${ROOT_ID}" \
--filter RESOURCE_CONTROL_POLICY \
--query "length(Policies[?AwsManaged==\`false\`])" \
--output text
# List all RCPs in the organization
aws organizations list-policies \
--filter RESOURCE_CONTROL_POLICY \
--query "Policies[*].{Name:Name,Id:Id,AwsManaged:AwsManaged}" \
--output tableUnlike SCPs, RCPs apply to the Management account. Ensure that RCP conditions include appropriate carve-outs for AWS service principals and Management account roles that require cross-account resource access for legitimate operational tasks (e.g. AWS Backup cross-account copy, CloudFormation StackSets).
Approved third-party SaaS integrations that require cross-account S3 access must be explicitly permitted via RCP condition keys (aws:PrincipalOrgID, aws:PrincipalArn) before deployment. Document each exception with vendor account ID and annual review date.
RCPs are a relatively new AWS feature and are not yet supported on all resource types - check the AWS documentation for the current list of supported services before drafting policies. Unlike SCPs, RCPs do apply to the Management account; this is intentional and means the Management account is protected by the same resource-side guardrails as member accounts. The FullAWSAccess RCP is attached by default at the root and must remain - custom RCPs are Deny additions on top of it, identical to the SCP model. RCP evaluation is AND-ed with SCP evaluation: both must allow the action. A Deny in either blocks the request regardless of what the other allows. Run Access Analyzer before applying any RCP to identify existing cross-account resource policies that would be affected.