When should organisations use RCPs instead of SCPs?

Use RCPs when the governance problem is resource-side access, such as controlling who can touch an S3 bucket, KMS key, or SQS queue. Use SCPs when the problem is the maximum privilege a principal can exercise across the organisation. Many cloud estates need both because they answer different questions.

Resource policies and service control policies solve different governance problems

RCPs and SCPs both constrain AWS usage, but they operate at different layers of the control plane. The practical question is not which one is “stronger”, but which layer you need to govern: the resource owner’s trust boundary, or the organisation’s ceiling on what principals can do anywhere in the estate.

RCPs are the better fit when the asset itself should decide who can interact with it, or under what conditions. That matters for resources with clear ownership or blast-radius boundaries, where the same principal may be acceptable in one environment or account but not another. NIST Cybersecurity Framework 2.0 is a useful lens here because it separates governance intent from the specific technical mechanism used to enforce it.

SCPs sit one layer higher and are used to define the organisation-wide ceiling for permissions. They are the right tool when you need to ensure that even highly privileged principals cannot exceed a central policy boundary, regardless of what a local account, role, or application policy might allow.

Where each policy type is most effective in practice

Use RCPs when the key decision is “who can touch this resource?” This is common for buckets, queues, keys, and other shared services where the owner wants to restrict access at the resource boundary without relying only on identity-side permissions. In that model, the resource policy becomes part of the asset’s security posture, not just an attachment to an identity.

Use SCPs when the key decision is “what is the maximum any principal in this account or organisation may do?” That makes SCPs especially valuable for guardrails: blocking dangerous actions, limiting service use in restricted environments, or preventing exceptions from bypassing central governance. The result is coarse but powerful control over the top end of privilege.

In mature cloud governance, the two are complementary rather than competing. A resource policy can allow a specific access path, while an SCP can still prevent a class of high-risk actions from ever being exercised. In practice, that combination is what closes the gap between local ownership and central enforcement.

How to choose the right boundary without creating policy conflicts

The cleanest selection rule is to ask which side of the access decision you are trying to govern. If the concern is resource exposure, cross-account sharing, or who may interact with one specific asset, start with the resource policy. If the concern is organisational guardrails, privilege ceilings, or limiting what accounts and roles can ever do, start with the SCP.

Do not use SCPs as a substitute for resource authorisation where the asset itself needs precise access rules. Likewise, do not expect an RCP to solve an organisation-wide prohibition problem. The strongest designs usually place the broad restriction in the SCP and the asset-specific allowance in the RCP, so the effective permission is the intersection of both.

NIST SP 800-53 Rev. 5 is a helpful control catalogue for thinking about this split, because it distinguishes access control, authentication, and configuration-related governance as separate control concerns rather than collapsing them into one policy layer.

Risk and Threat Considerations

The main risk is misplacing the control boundary and assuming one policy type covers the other. If you rely only on SCPs, resource-level exposure can persist through overly broad resource policies or cross-account grants. If you rely only on RCPs, local flexibility can leave the organisation without a hard ceiling on privileged actions.

Failure mechanism: A policy layer is chosen for the wrong governance problem, so access is either too permissive at the resource edge or too weak at the organisational ceiling. Attackers and insiders benefit when one layer permits what the other was meant to prevent.

Impact: The result can be unintended data exposure, over-broad admin actions, weaker separation between environments, and more difficult incident containment because effective privilege is determined by multiple interacting policies.

Practitioner Guidance

What to prioritise: Define whether each AWS control is meant to answer a resource-access question or an organisation-wide privilege question. That classification should be explicit in your standards, because ambiguous ownership is the most common reason teams apply the wrong policy type.

What to verify: Check the effective permission path, not just the policy document in isolation. A role can be allowed by one policy layer and still blocked by another, so review the combined result for the specific principal, action, and target resource you care about.

Common mistake: Treating SCPs as a generic replacement for access policy design. That usually creates false confidence, because the organisation may still have resource policies that re-open access paths the SCP was never intended to manage.

Practitioner takeaway: Use SCPs to set the organisational ceiling, and use RCPs to shape the resource’s own access boundary; the safest design is the one where both layers reinforce the same intent.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• How should security teams use IAST and RASP in NHI governance?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?