How do you audit who holds the AWS AWSSecurityHubReadOnlyAccess managed policy?

List all users, groups and roles attached to the AWS AWSSecurityHubReadOnlyAccess managed policy, then confirm that each principal only needs to view Security Hub data. Read-only access still exposes findings and security posture information, so inherited group membership matters. Remove stale attachments and review any role used by analysts, auditors or automation.

What “auditing who holds the policy” actually means in AWS

To audit AWS managed policy attachments, work from the policy outward: identify every user, group, and role that has AWSAWSSecurityHubReadOnlyAccess attached, then trace each attachment to the actual human or workload that can assume that identity. The key question is not just attachment count, but whether the effective access still matches the principle of view-only Security Hub usage.

Because group membership and role assumption can widen access beyond the obvious direct attachment, the audit should include inherited access paths and temporary assumptions, not only the principals you see in a single console view. For AWS policy analysis and role-trust relationships, use the AWS IAM Policies and Roles Guide as the reference for policy evaluation logic and trust-chain review.

Practically, that means checking whether the policy is attached directly to a user, inherited through a group, or granted to a role that is assumed by analysts, auditors, automation, or another workload. A clean audit should let you answer three things clearly: who has the policy, why they have it, and whether the attached principal is still the right place to carry that read-only permission.

How to trace effective access in the AWS control plane

The most reliable audit method is to inventory the policy attachments first, then validate each principal against the business need. In AWS, that usually means reviewing IAM users and groups for direct attachments, then examining IAM roles and their trust policies to see who or what can assume them. If a role is used by multiple systems, the role itself may be appropriate while the downstream assumptions are not.

Read-only Security Hub access can still reveal sensitive findings, posture details, security metadata, and environment structure. That makes the review broader than simple privilege checking, because information exposure can matter even when no write action is possible. A role that is “read only” for Security Hub may still be too broad if it is shared across teams, reused across environments, or attached to automation that does not need the data.

Where the attachment is indirect, confirm the whole chain: principal, group, role, session, and the workload or person that ultimately uses it. This is especially important when access is inherited through common team groups or reused cross-account roles, because the obvious attachment point may not be the real consumer of the data. The Cloud Workload Identity Guide is useful when you need to reason about roles, STS, and temporary credentials as part of the access path.

What to remove, keep, or tighten after the audit

Once you have the attachment list, classify each principal by necessity. Keep the policy only where the principal genuinely needs to inspect Security Hub findings as part of a defined job function; remove it where the access is stale, inherited by convenience, or granted to a role that has grown beyond its original purpose. If the principal exists mainly for audit, prefer a narrowly scoped audit role over a broadly reused operational role.

If you find analysts, auditors, or automation sharing the same role, treat that as a design smell. Those use cases usually have different access lifecycles, different review frequencies, and different accountability requirements. Separation matters because the role that is convenient for recurring review can become the role that quietly accumulates unnecessary visibility over time.

For AWS-specific policy hygiene, keep the policy attachment narrow, document the business reason for every exception, and remove principals that no longer need Security Hub visibility. The Ultimate Guide to NHIs, Regulatory and Audit Perspectives helps frame why recurring access review and accountability matter when roles and automation hold audit-visible permissions.

Risk and Threat Considerations

Read-only access is not harmless when it exposes security findings, account posture, or investigation details. If the policy is attached too broadly, an insider or compromised role can harvest sensitive visibility into defensive controls, weak configurations, and the organisation’s security state without needing write access.

Failure mechanism: Excessive or stale attachments, especially through groups or reusable roles, create hidden read paths that survive team changes and role reuse. Those paths can be abused for reconnaissance, target selection, or quiet monitoring of security posture.

Impact: Exposure of Security Hub data can widen the blast radius of an account compromise, leak operational security intelligence, and undermine separation between people who need visibility and people who should not have it. If the role is also assumed by automation, the exposure can scale across many sessions and environments.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Tracks which users, groups, and roles hold the policy.
	AC-6 — Least Privilege	View-only Security Hub access should be limited to principals with a real need.
	AU-6 — Audit Review, Analysis, and Reporting	Security Hub access should be reviewed as part of access governance and monitoring.
Recommendation — Review policy attachments and remove accounts that no longer need Security Hub visibility. Restrict the policy to principals that require Security Hub findings for their job duties. Use review evidence to confirm who can view security findings and why.
CIS Controls v8	CIS-5 — Account Management	Covers inventorying and pruning human and service accounts with access.
Recommendation — Inventory attached principals and remove stale policy assignments.
CSA Cloud Controls Matrix	IAM — Identity and Access Management	Cloud IAM governance directly governs AWS managed policy attachment and review.
Recommendation — Map the managed policy to accountable identities and revalidate access necessity.

Practitioner Guidance

What to verify: Check the direct attachment list, then verify group membership and role trust so you are auditing effective access, not just visible attachments. If the principal can be assumed by multiple actors, identify the real user or workload behind each assumption.

Decision rule: If the principal only needs to read Security Hub data for a defined task, keep the policy but narrow ownership and review cadence; if the role is shared, stale, or not clearly justified, remove or replace it rather than accepting “read only” as sufficient.

Practitioner takeaway: The real control is not just finding attached principals, it is proving that every attachment still maps to a current, necessary, and accountable viewing need.