IAM policy analysis tells you what a principal is allowed to attempt, while CloudTrail shows what was actually attempted or succeeded in practice. In this use case, IAM may indicate broad assume-role capability but still hide the target account and role name. CloudTrail closes that gap by surfacing real role assumption activity across accounts.
Why IAM Policy Analysis and CloudTrail Answer Different Questions
iam policy analysis and CloudTrail are both useful for cross-account access review, but they answer different questions. Policy analysis is a static control view: it tells you what permissions exist on paper. CloudTrail is an execution view: it tells you whether those permissions were exercised, by whom, and in which account context. That difference matters when you are trying to prove actual cross-account access rather than infer it.
In practice, policy analysis is strongest for finding latent paths such as broad assume-role permissions, trust relationships, and overly permissive statements. It is the right first pass when you want to understand exposure before activity occurs. CloudTrail becomes more valuable when you need to confirm whether a path was used, whether a role assumption succeeded, and whether the access pattern is repeated or unusual.
The two views complement each other because a permission may exist without being used, and a used path may only be visible in event history. If you only analyze IAM, you may miss the operational reality of cross-account activity. If you only review CloudTrail, you may miss dormant but dangerous permissions that have not yet been exercised.
What Each Method Can and Cannot Reveal
IAM policy analysis can surface the possibility of cross-account access even when the target account or specific role name is not obvious. This happens because policy language can expose broad assume-role capability without showing the full downstream path in a simple account-by-account inventory. That makes it excellent for identifying blast radius, but weaker for proving actual access events.
CloudTrail closes that gap by logging real API activity, including role assumption attempts and successful assumptions across accounts. It can show the actor, timing, source context, and target role details that policy inspection may not make obvious. For an investigator, that means CloudTrail is usually the better source for answering “did this happen?” while IAM is better for answering “could this happen?”
The practical distinction is important for triage. If the goal is access discovery, policy analysis may overstate risk by showing unused permissions. If the goal is incident review or assurance, CloudTrail is more grounded because it reflects what was actually attempted or completed. A mature review usually uses both: policy for surface area, CloudTrail for evidence of use.
How Practitioners Should Combine the Two
Start with IAM policy analysis when you are mapping cross-account exposure at scale, because it helps you build the universe of possible paths. Then use CloudTrail to validate which of those paths are active and whether activity matches expected business use. That sequence avoids treating every allowed path as a live incident while still preventing an overreliance on logs alone.
For the strongest results, correlate trusted relationship statements, assume-role permissions, and CloudTrail role-assumption events across the accounts involved. When policy analysis shows a path but CloudTrail is silent, treat that as dormant exposure rather than proof of safety. When CloudTrail shows repeated assumptions, treat the account pair and role chain as an operational dependency that deserves ownership and review.
What to verify: Confirm that the role session in CloudTrail maps back to the intended trust relationship, and that the assumed role is still required by the business process. If the policy allows cross-account access but CloudTrail never records legitimate use, the permission is often a candidate for tightening or removal.
Practitioner takeaway: Use IAM policy analysis to discover possible cross-account access, then use CloudTrail to prove actual use; the security answer changes from “is it allowed?” to “did it happen?”
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Cross-account access discovery depends on audit trails that record role assumption activity. |
| AU-6 — Audit Record Review, Analysis, and Reporting | CloudTrail is only useful if its events are reviewed and correlated with policy findings. | |
| AC-6 — Least Privilege | Policy analysis exposes excessive cross-account permissions that should be minimised. | |
| Recommendation — Log cross-account role assumptions and retain audit events for investigation. Review CloudTrail role-assumption events and correlate them with policy exposure. Remove unused cross-account permissions and narrow assume-role paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is about discovering and governing who can and did access across accounts. |
| CIS-8 — Audit Log Management | CloudTrail is an audit-log source used to confirm real access activity. | |
| Recommendation — Inventory cross-account access paths and revoke unnecessary permissions. Centralise and review audit logs for cross-account role assumptions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Cross-account access review is fundamentally an access-control governance problem. |
| A.8.15 — Logging | CloudTrail provides the log evidence needed to validate actual cross-account use. | |
| Recommendation — Define and enforce approved cross-account access relationships. Enable and retain logs that show cross-account access events. | ||
Related resources from NHI Mgmt Group
- What is the difference between policy review and effective permission analysis in OCI IAM?
- What is the difference between policy-based access control and manual access administration in IAM?
- What is the difference between AWS SSO based access and relying on separate IAM users for each account?
- What is the difference between cloud IAM based access and Kubernetes service account based access for managed clusters?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
