Role Pattern Library

Deliberately excluded: siem:case:delete, every iam:* action, and every billing/subscription action.

siem:caseassignment:update is scoped to the manager's own team's cases and teammates.

Deliberately excluded: No create, update, or delete actions anywhere in this role - an auditor's value comes specifically from having no ability to alter the record they're reviewing.

siem:report:read is scoped to every report period, since an audit often spans a full year.

Deliberately excluded: Every siem:incident:* and siem:case:* action, and every iam:* action - this role isn't meant to triage security events, only keep the fleet itself healthy and connected.

siem:inventory:read is granted across all inventory categories.

Deliberately excluded: Nothing else - no Log Analysis, no case or incident detail, no IAM visibility. This is intentionally the narrowest pattern in the library: it answers "how are we doing," not "what specifically happened."

siem:report:read is scoped to monthly and quarterly periods only, not daily/weekly operational detail.

Every read permission is restricted to the specific subset of assets covered by the engagement. If the engagement occasionally needs deeper access, grant that through a scoped assumable role rather than standing access.

Deliberately excluded: Case management and IAM actions - this role's job is the detection layer itself, not the response workflow built on top of it.

Also granted the alert-threshold and rule-muting actions for the specific assets this engineer is responsible for tuning.

Deliberately excluded: siem:workspace:delete and siem:widget:delete outside of items they personally own, so a builder can iterate freely on their own work without being able to remove workspaces built by others.

Asset-restricted to whatever data the builder is themselves permitted to see, which automatically bounds what any workspace they build can expose.

Deliberately excluded: siem:subscription:cancel (often reserved for the Account Owner specifically, as a deliberate friction point against an accidental or unauthorized cancellation), and every security/IAM action in the catalog.

Unrestricted across assets rather than scoped, since an active incident's scope isn't known in advance. Trust policy: verification code required, session capped at a short duration appropriate to how long a typical incident response takes in your environment.

Deliberately excluded: iam:policy:create/update/delete (policy authorship stays with a senior administrator), iam:role:attachBoundary/detachBoundary, and all guardrail-policy actions - none of which the Account Owner would grant to a new IAM administrator under the ceiling rule until that administrator's own access covers them anyway.