Vol VII Book 08 — Federal Compliance — Native Cloud IAM/RBAC Access-Governance Automation

Azure RBAC and AWS IAM entitlement drift, surfaced by SailPoint ISC Governance and operated as ServiceNow work

0.1 Draft Proposal — Subject to Review

Developed by the CSI Team (Cloud Services Infrastructure); not yet reviewed or approved by the Agency CIO Office, OIS, or leadership. Date Code: 2026-07-29 16:45 ET

Series Context — Volume VII Book 08. The identity/entitlement lane of the coordination layer, extending the same pattern Books 03/06/07 run for Azure, AWS, and VMware configuration/vulnerability/patch controls into the adjacent access-governance domain (AC-2, AC-3, AC-6). This is not a second front door. SailPoint ISC Governance (the CIEM add-on) is a detection engine, structurally identical to how Defender for Cloud, Security Hub, and VCF Operations feed the same ServiceNow-coordinated pipeline the earlier platform books already use. Actuation stays platform-native — an Azure RBAC role revoke or an AWS IAM policy rescope makes the change; ServiceNow governs ownership, SLA, approval, and evidence, exactly as it does for every other control family in this volume.

1 What This Document Addresses

Books 03, 06, and 07 close CM-6/RA-5/SI-2 by routing native configuration, posture, and patch findings through ServiceNow. The same evidence gap exists one plane over: Azure RBAC role assignments and AWS IAM policies can be inspected, and even remediated, entirely through their native consoles — and a native IAM console has the identical evidence problem the configuration-drift argument describes. A role binding is not, by itself, a record of who requested it, who approved it, and when it was last reviewed. This book closes AC-2 (Account Management), AC-3 (Access Enforcement), and AC-6 (Least Privilege) for the native cloud IAM/RBAC surface the same way the earlier books close their controls: test the native state, detect drift against intended entitlement, raise a typed ServiceNow task, actuate on the native surface, close with evidence.

Consistency, not a parallel system. This book does not stand up SailPoint as a second coordination layer alongside ServiceNow. SailPoint’s own product architecture routes its findings into ServiceNow’s Service Desk for ticketing and audit tracking rather than trying to be a standalone evidence system — so this book routes SailPoint ISC Governance findings into the identical ServiceNow pipeline Books 02–07 already use. One front door, regardless of which control family the finding belongs to.

2 The IAM/RBAC Control Engine and Its Coordination Role

Unlike the configuration/posture/patch books, where each cloud carries three distinct native engines, the identity/entitlement surface is covered by one cross-cloud detection engine reading two native surfaces:

Engine	Owns (actuation)	Reads	Controls	ServiceNow coordination role
SailPoint ISC Governance (CIEM)	Nothing — read-only observer, ssot-mutation: never	Azure RBAC role assignments; AWS IAM policies and roles	AC-2, AC-3, AC-6	Over-privileged / idle / over-broad finding → prioritized Change task; SLA by exposure
Azure RBAC (native)	Role assignment revoke/rescope	—	AC-2, AC-3, AC-6	Actuates the change ServiceNow’s task authorizes
AWS IAM (native)	Policy/role revoke/rescope	—	AC-2, AC-3, AC-6	Actuates the change ServiceNow’s task authorizes

This engine is bounded to Azure and AWS, by evidence — not by doctrine. SailPoint ISC + CIEM natively governs cloud IAM entitlements across AWS, Azure, and GCP; no evidence was found, after direct research, that its CIEM add-on reaches VMware/vCenter permissions. This book covers Azure RBAC and AWS IAM only. VMware’s identity/RBAC surface is a genuinely open gap — see Honest Limits — not a scope the series has deferred by choice the way OCI patch orchestration was deferred in Books 06/07. GCP IAM is in scope for a later follow-up (SailPoint’s own coverage extends there; this book’s first pass matches the two clouds Books 03 and 06 already cover).

3 Control Engine — SailPoint ISC Governance / CIEM (AC-2 / AC-3 / AC-6)

SailPoint Identity Security Cloud’s Cloud Infrastructure Entitlement Management (CIEM) add-on discovers identities and permissions across Azure and AWS, flags over-privileged accounts, identifies entitlements idle 90 or more days, and surfaces over-broad role/policy bindings. It is a read-only governance-plane observer — it does not itself revoke or rescope anything, and it holds no write authority over any identity plane it reads.

• Test: entitlement state is read per identity/role across Azure RBAC and AWS IAM — assigned roles, effective permissions, last-used timestamps.
• Detect + Raise: an over-privileged, idle, or over-broad finding becomes a ServiceNow Change tagged with the mapped control (AC-2/AC-3/AC-6), severity, and the reconciled identity/resource CI. An access exception is not silent — it is a request with an approver and an expiry, the same discipline as every configuration exception in Books 03/06/07.
• Actuate: the owning team revokes or rescopes the entitlement directly on the native surface — an Azure RBAC role-assignment removal, or an AWS IAM policy edit. ServiceNow does not write the entitlement.
• Close: the next CIEM scan confirms the entitlement is revoked or rescoped; ServiceNow closes and stamps the evidence.

CIEM findings are a point-in-time scan, not continuous enforcement. SailPoint’s entitlement scan runs on a schedule; an entitlement granted and misused between scans is not caught until the next cycle. This is the identical latency property Security Hub CSPM and Defender for Cloud already carry in Books 03/06 — the reconciliation loop’s evidence timestamp records the scan cycle, not the instant of drift.

4 Continuous Monitoring Roll-Up (CA-7)

The engine’s loop emits its result into the continuous-monitoring feed: entitlement-review completion, open over-privilege findings by age, idle-entitlement remediation SLA conformance. ServiceNow rolls these into a per-control identity posture that Vol VII Book 04 turns into attestation and KSI evidence, keyed to the same reconciled asset identity the M365, Azure, AWS, and VMware postures use — one compliance picture, not a fifth parallel one.

5 Closure Necessity

5.1 Closure Necessity — SailPoint observes; the estate still needs an owner and a clock

SailPoint ISC Governance discovers over-privileged and idle cloud entitlements with genuine precision — the native stack is sufficient to find the problem. What it does not supply, by design, is the governance wrapper: who owns this finding, by when, under whose approval, with what evidence. Strip the coordination layer and the CIEM dashboard shows a clean entitlement graph while the authorization package has no owned-and-evidenced record an assessor can trace. AC-2, AC-3, and AC-6 are surfaced by SailPoint; they are operated — owned, clocked, evidenced — here, on the identical ServiceNow pipeline every other control family in this volume already uses.

6 NIST SP 800-53 Rev 5 Control Closure — Authorities Closed Here

Generated from the series compliance spine (federal-compliance-compliance-spine.yml) by render_authorities_table.py; not hand-edited here. Coordination closures — the Azure RBAC/AWS IAM entitlement state operated as tracked work — not a re-closure of the identity-lifecycle mechanisms Vol IX Book 06 owns.

Authorities Closed Here — Native Cloud IAM/RBAC Access-Governance Automation († = Closure-Necessity anchor: no alternate closure path)

Control	Title	Closing mechanism (function, not product)	Accreditation gate	Authority drivers	Evidence slot	FedRAMP 20x KSI	Tool-attestable?
AC-2	Account Management	SailPoint ISC Governance (CIEM) findings on Azure RBAC and AWS IAM — over-privileged and idle entitlements — raised as ServiceNow remediation tasks; native IAM console actuates the revocation/rescoping, ServiceNow tracks to closure	FedRAMP Moderate	NIST SP 800-53 Rev 5; OMB M-22-09	Identity	KSI-IAM	No
AC-3	Access Enforcement	Over-broad Azure RBAC/AWS IAM policy bindings surfaced by SailPoint ISC Governance become ServiceNow Change tasks with owner and approval before rescoping; the native role/policy binding remains the enforcement point the agency controls	FedRAMP Moderate	NIST SP 800-53 Rev 5	Identity	KSI-IAM	No
AC-6	Least Privilege	SailPoint CIEM identifies entitlements idle 90+ days on Azure RBAC and AWS IAM; ServiceNow raises a scoped-SLA remediation task tracked to closure with re-test evidence	FedRAMP Moderate	NIST SP 800-53 Rev 5; OMB M-22-09	Identity	KSI-IAM	No

7 Honest Limits

• VMware/vCenter permissions are not covered. No evidence was found that SailPoint CIEM (or any surveyed alternative) reaches vSphere/vCenter role and permission governance. This is a genuine, unaddressed gap, not a deferred-by-choice scope the way OCI patch orchestration is in Books 06/07 — it should not be cited as though it were closed.
• GCP IAM is a later follow-up. SailPoint’s CIEM coverage extends to GCP; this book’s first pass matches Azure and AWS to mirror the two clouds already covered elsewhere in this volume.
• CIEM findings lag actual state by a scan cycle, identically to Security Hub CSPM and Defender for Cloud in Books 03/06 — “closed” reflects the scan that confirmed it, not the instant the change landed.
• This book does not duplicate Vol IX Book 06. Vol IX Book 06 closes AC-2/AC-5/AC-6 through HR-event-driven JML automation and calendar-based certification campaigns — a different trigger (an HR event or a schedule) than this book’s trigger (a native-cloud entitlement scan finding drift). The two books close overlapping controls through genuinely different mechanisms over different surfaces; neither substitutes for the other.
• This coordination pattern describes an integration design, not a claim of an active, deployed tenant integration today. As with the scoped ServiceNow app in Book 05, standing this up in production requires its own sub-production review and sign-off before any live connector is enabled.

8 Cross-References

• Vol VII Book 03 (Azure) / Book 06 (AWS) / Book 07 (VMware) — the sibling coordination books this one extends into the identity/entitlement plane; all now reconcile into the same ServiceNow queues.
• Vol VII Book 01 — the reconciled CIs every IAM/RBAC task is raised against; Vol VII Book 04 — where the identity posture roll-up becomes attestation.
• Vol IX Book 06 (Identity & Access Governance) — the JML-automation and certification-campaign lane this book does not duplicate; see Honest Limits.
• ticket-to-machine-not-ticket-to-human whitepaper — the customer-facing synthesis this book’s closure supports.

9 Provenance

Draft. SailPoint ISC Governance / CIEM, Azure RBAC, and AWS IAM are deployed examples; the detect→raise→actuate-native→close→evidence loop is the invariant, identical to the M365, Azure, AWS, and VMware books. Vendor claims cite vendor documentation (see References) and are dated, not permanent — see the Vendor Currency Doctrine. This book’s entire premise rests on a capability inventory (SailPoint CIEM’s cloud coverage, its VMware gap) taken directly from that week’s vendor research; confirm SailPoint’s, and each CSP’s, current entitlement-governance roadmap before this book informs a Project Plan. The compliance-loop figure is authored as committed house-style SVG.

10 References

Claim	Source
SailPoint CIEM — native AWS/Azure/GCP cloud IAM entitlement governance, over-privileged/idle-entitlement discovery	SailPoint — https://www.sailpoint.com/products/identity-security-cloud/atlas/add-ons/cloud-infrastructure-entitlement-management
SailPoint routes findings into ServiceNow’s Service Desk for ticketing/audit tracking	SailPoint — https://www.sailpoint.com/products/connectivity-and-integrations/catalog/servicenow
No confirmed VMware/vCenter CIEM coverage (Honest Limits basis)	Direct research, 2026-07-28 — no vendor documentation found asserting this coverage
ServiceNow as workflow/CMDB/evidence coordination hub	Expansion Plan §16 — docs/customer-documents/federal-compliance-series/Compliance_Series_Expansion_Plan_Substrate_Accreditation.md