Resource Control Policy

Expanded Definition

Resource Control Policy, or RCP, is an AWS organisation-level policy that governs the resource side of access decisions. Rather than focusing only on who can call a service, it sets boundaries on what a resource will allow, making it especially useful for services that expose sensitive data, cross-account sharing, or privileged control planes.

In practice, RCPs complement service control policies by reducing the chance that an identity policy alone can overreach. That distinction matters in NHI governance because service accounts, workload roles, and automation paths often accumulate permissions faster than they are reviewed. For a broader NHI control context, see Ultimate Guide to NHIs — Standards and the NIST Cybersecurity Framework 2.0.

Definitions vary across vendors and cloud providers, but the core idea is consistent: resource-side policy is a guardrail, not a substitute for strong identity design, least privilege, or secret hygiene. The most common misapplication is treating an RCP as a replacement for identity policy, which occurs when teams rely on resource boundaries after over-permissioned NHI roles have already been created.

Examples and Use Cases

Implementing RCPs rigorously often introduces policy complexity, requiring organisations to weigh tighter resource isolation against the operational cost of managing more restrictive access rules.

• A data platform team applies an RCP to sensitive storage resources so only approved organisational paths can read or write data, even when an NHI role is broadly trusted elsewhere.
• A cross-account automation workflow uses an RCP to ensure only designated service principals can interact with a control plane, limiting exposure if a workload role is later abused.
• A security team pairs RCPs with findings from the Top 10 NHI Issues to reduce the blast radius of excessive privileges and overexposed service accounts.
• A cloud governance program uses RCPs alongside AWS identity policies to block unsafe resource access patterns while still allowing normal application operations.
• An engineering group references Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs when deciding whether a workload should access resources directly or through a narrower brokered path.

Why It Matters in NHI Security

RCPs matter because NHI risk often emerges where identity controls look correct but the resource itself is still too permissive. That gap is common in large AWS environments, especially when machine identities are reused across teams, accounts, or automation pipelines. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which makes resource-side guardrails particularly important for reducing blast radius and preventing lateral access.

RCPs support zero trust by enforcing policy at the resource boundary rather than assuming that authenticated automation should be trusted by default. They are most valuable when sensitive data stores, administrative APIs, or shared platform services need explicit denial conditions that identity policy alone cannot express. For audit and governance context, see Ultimate Guide to NHIs — Regulatory and Audit Perspectives and the NIST view of continuous risk reduction in NIST Cybersecurity Framework 2.0.

Organisations typically encounter the need for RCPs only after a service account reaches a resource it should never have touched, at which point resource-side containment becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Control Monitoring
• When does policy-based access control reduce risk for NHI environments?
• When does policy-based access control fail for workloads and agents?
• What is the difference between CSPM and policy-based access control?