How do you audit who holds the AWS AWSLambdaBasicExecutionRole Managed Policy?

What it means to audit an AWS managed policy attachment

Auditing who holds AWSLambdaBasicExecutionRole is really an entitlement review, not just a document check. The practical question is which IAM roles inherit the policy, which Lambda functions assume those roles, and whether those functions still need the logging and execution permissions the policy grants. That is the control point where excess access, stale roles, and hidden blast radius show up.

Because the policy is attached to roles rather than functions directly, the review should trace the permission chain end to end. A role can be reused across multiple functions, and a function can survive long after its original owner forgets why the role exists. AWS IAM Policies and Roles Guide is the most direct place to refresh the mechanics of policy attachment, role trust, and evaluation logic before you classify an attachment as justified or excessive.

If the policy is still needed, the next judgement is whether the attachment is appropriately scoped for the current workload. In practice, that means checking for functions that no longer emit useful logs, roles that were copied forward from templates, and environments where the same role has spread beyond its original purpose. The audit should end with a clear inventory of roles, the Lambda functions they support, and the business reason each attachment still exists.

How to build the audit trail and confirm exposure

The audit trail starts with the IAM role list, then moves to the Lambda inventory, then back to the policy attachment. That sequence matters because it lets you prove both possession and use: who has the policy, which function consumes the role, and whether the function is active or abandoned. A role attached to a live production function is a different risk from one attached to a disabled test function, even if the policy name is the same.

For a useful review, pair the attachment list with an ownership check. Every role should map to a function owner or platform owner who can explain why the execution and logging permissions are still required. If that explanation is missing, the role is effectively ungoverned even if the attachment is technically valid.

Internal audit should also look for role reuse patterns that conceal excessive access. Shared roles make it harder to tell whether one function really needs a permission or whether the permission survives only because another function still depends on it. Cloud Workload Identity Guide helps frame that review around workload identity sprawl, temporary credentials, and reuse risks rather than treating the policy as an isolated object.

When the review is part of a broader assurance or third-party evidence process, the relevant evidence is not just the attachment list. You want the role-to-function mapping, the approval or rationale for each attachment, and the date of the last recertification so you can show the control is current rather than historical.

When to remove, tighten, or escalate the finding

Once the role mapping is complete, the decision usually falls into one of three buckets: keep it, narrow it, or remove it. Keep it only when the function still needs the permissions and the role is clearly owned. Narrow it when the function needs some, but not all, of the capabilities implied by the attached policy. Remove it when the function is gone, the role is unused, or the attachment exists only because nobody has reviewed it recently.

Escalate any case where the role supports a production Lambda function but the owner cannot explain why the permissions remain necessary. That is often a sign of permission drift, copied infrastructure, or a forgotten dependency. It is also the point where a policy review becomes a change-management issue, because removing the attachment may break logging or execution if the underlying architecture was never documented.

For assurance teams, the standard is not perfection, but defensibility. If a role is attached to a policy simply because it always has been, the audit is already useful: it has identified an entitlement that survived beyond its original justification. SOC 2 Trust Services Criteria (AICPA) is relevant here because the same evidence discipline supports access reviews, change traceability, and confidence that permissions are reviewed on a recurring basis.

Risk and Threat Considerations

Stale Lambda execution roles create a quiet privilege accumulation problem. If a policy remains attached after the function's purpose has changed, an attacker who compromises that function or its deployment path may inherit more logging or execution capability than the workload actually needs. The risk is not the policy name itself, but the persistence of unnecessary trust in a role that is no longer actively justified.

Failure mechanism: Role reuse, missed recertification, or copied infrastructure leaves AWSLambdaBasicExecutionRole attached long after the workload moved on, which preserves excess permissions and widens blast radius if the function or deployment pipeline is compromised.

Impact: Unneeded execution and logging permissions can support broader lateral movement, noisier incident response, and harder-to-explain access exposure during audit or post-incident review.

Practitioner Guidance

What to verify: Confirm each attached role still maps to an active Lambda function and that the function owner can justify the permission set in operational terms, not just by naming the policy.

What to prioritize: Focus first on shared roles, production functions, and any attachment with no recent recertification because those are the cases most likely to hide unnecessary standing access.

Practitioner takeaway: The key judgement is whether the policy is still needed for a living function, because the real control failure is not overattachment by name, but unmanaged permission persistence by role.

Related resources from NHI Mgmt Group

• How do you audit who holds the AWS AmazonBedrockFullAccess managed policy?
• How do you audit who holds the AWS AmazonDynamoDBReadOnlyAccess managed policy?
• How do you audit who holds the AWS AmazonEKSClusterPolicy managed policy?
• How do you audit who holds the AWS IAMAccessAnalyzerReadOnlyAccess managed policy?